lkml.org 
[lkml]   [2003]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [patch] e1000 TSO parameter
>>>>> On Mon, 14 Jul 2003 22:38:22 -0700, "David S. Miller" <davem@redhat.com> said:

DaveM> But I don't think that's what is happening here, rather the
DaveM> PCI controller is "talking" to the CPU's L2 cache with
DaveM> coherency transactions on all the data of every packet going
DaveM> to the chip.

That's true. But shouldn't it be true for both the TSO and non-TSO
case?

DaveM> Whereas with a sendfile() type setup, the PCI controller is
DaveM> going straight to main memory for the data part of the
DaveM> packets since the CPU is unlikely to have each page cache
DaveM> page in it's L2 caches.

But sendfile() was _not_ used in any of the tests. The ftp server
installed no the machine doesn't use it (not to my knowledge, at
least) and netperf only uses it for the SENDFILE test.

DaveM> I know how this can be fixed, can you use L2-bypassing stores
DaveM> in your csum_and_copy_from_user() and copy_from_user()
DaveM> implementations like we do on sparc64? That would exactly
DaveM> eliminate this situation where the card is talking to the
DaveM> cpu's L2 cache for all the data during the PCI DMA transation
DaveM> on the send side.

We could, but would it always be a win? Especially for
copy_from_user(). Most of the time, that data remains cached, so I
don't think we'd want to use non-temporal stores on those (in
general). csum_and_copy_from_user() isn't well optimized yet. Let's
see if I can find a volunteer... ;-)

--david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.065 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site