[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101210143140.GD3536057@jupiter.n2.diac24.net>
Date: Fri, 10 Dec 2010 15:31:40 +0100
From: David Lamparter <equinox@...c24.net>
To: Michał Mirosław <mirqus@...il.com>
Cc: David Miller <davem@...emloft.net>, bhutchings@...arflare.com,
srk@...com, netdev@...r.kernel.org
Subject: Re: Adding Support for SG,GSO,GRO
On Fri, Dec 10, 2010 at 03:18:11PM +0100, Michał Mirosław wrote:
> I'm trying to understand the dependency because it looks artificial for me.
You have the data you want to send in the RAM, somewhere, possibly
scattered. The application calls sendfile(). The kernel puts the
transmission in the network card's queue, which might already have lots
of entries.
A millisecond later - an eternity for the CPU - the card decides to do
the transmission.
However, the data might have changed in the meantime.
sendfile() is defined so that it works asynchronously, that means if you
change the data while it is in the queue, you get unpredictable results.
But, what you should NOT get is packets with an invalid checksum.
Whatever data you are sending, it needs to have a correct checksum.
Now, if the card does the checksum itself, everything is fine. But what
are you supposed to do if the card can't checksum? Call back the kernel
at the point where the card does the TX? That's pointless (and racy).
Pre-calculate the Checksum at submission time? Doesn't work, you would
have to make a copy of the data, so it doesn't change anymore, so the
checksum stays correct. But not copying the data is the whole point of
sendfile().
You see why SG without HW checksum is useless here?
-David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists