netdev - Re: Adding Support for SG,GSO,GRO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=vB-9bo09AhE7GTEJ1iPQd+nE=tfcFY+GmKUt-@mail.gmail.com>
Date:	Fri, 10 Dec 2010 09:27:49 +0100
From:	Michał Mirosław <mirqus@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	"Govindarajan, Sriramakrishnan" <srk@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Adding Support for SG,GSO,GRO

W dniu 9 grudnia 2010 19:58 użytkownik Ben Hutchings
<bhutchings@...arflare.com> napisał:
> On Thu, 2010-12-09 at 19:47 +0100, Michał Mirosław wrote:
>> 2010/12/9 Ben Hutchings <bhutchings@...arflare.com>:
>> > On Thu, 2010-12-09 at 16:03 +0530, Govindarajan, Sriramakrishnan wrote:
>> >> Hi
>> >> We have a NAPI compliant driver(net/drivers/davinci_emac.c), that does
>> >> well at 10/100Mbps loads. Now the same controller/driver is used for
>> >> 1000Mbps
>> >> mode as well, where the CPU gets saturated easily
>> >>
>> >> Internally the module supports scatter gather DMA(which is currently not
>> >> exercised) but there is no HW checksum support.
>> >>
>> >> To specifically implement GRO, GSO support would it be sufficient to add
>> >> SG support to the driver? Are there other means of increasing the throughput
>> >> and decreasing the CPU loading?
>> [...]
>> > On the TX side, NETIF_F_SG means that the stack may include data in the
>> > skb by reference to arbitrary pages *even if their contents are still
>> > being changed* (think sendfile()), which means it depends on hardware
>> > checksum generation.
>>
>> Isn't that condition too broad? If the data could change after packet
>> is submitted to the driver then results would be unpredictable and
>> allow sending wrong data with correct (because hw-calculated)
>> checksum.
> This is not done for a regular send(), only for functions such as
> sendfile() which are specified to read the data asynchronously.
>
>> Right now NETIF_F_SG is removed from dev->features by
>> netdev_fix_features() if no checksum offloads are enabled.
>>
>> Just an idea: would driver with NETIF_F_SG|NETIF_F_HW_CSUM using
>> skb_checksum_help() in xmit path work? This would allow to use DMA
>> scatter-gather without hardware checksumming (and avoid copying the
>> packet's data before sending).
> No, you cannot calculate a checksum for the fragments without also
> copying them to ensure the data doesn't change afterward and invalidate
> the checksum.  You could in theory make a copy into multiple fragments,
> but there's no point in doing that unless the frame size is larger than
> a page.

Then at least couple of drivers are broken in this way (ibmveth,
chelsio for UDP, there are other hits on skb_checksum_help).

I'm not familiar with splice/sendfile code, but I would expect, that
pages transferred with it have to be submitted after "data ready"
notification and pinned in memory by DMA mapping (with hardware
checksumming, CPU does not need to see the data, but still it has to
be there already) until the frame is transferred to the network
device. So, even if the contents of the page changes (because further
data is transferred), the part that is submitted to be sent should
not.

If that's really not the case, then splice/sendfile to network is
useless as it means random data corruption. Googling around shows
reports about sendfile() correllated corruption - could this the
cause?

Best Regards,
Michał Mirosław
--
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