netdev - Re: [PATCH v2 RFC 0/13] Remove UDP Fragmentation Offload support

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: <20170708.104733.1084990812481085646.davem@davemloft.net>
Date:   Sat, 08 Jul 2017 10:47:33 +0100 (WEST)
From:   David Miller <davem@...emloft.net>
To:     mkubecek@...e.cz
Cc:     netdev@...r.kernel.org, willemdebruijn.kernel@...il.com
Subject: Re: [PATCH v2 RFC 0/13] Remove UDP Fragmentation Offload support

From: Michal Kubecek <mkubecek@...e.cz>
Date: Fri, 7 Jul 2017 14:45:31 +0200

> On Fri, Jul 07, 2017 at 10:43:26AM +0100, David Miller wrote:
>> 
>> This is an RFC patch series, based upon some discussions with
>> various developers, that removes UFO offloading.
>> 
>> Very few devices support this operation, it's usefullness is
>> quesitonable at best, and it adds a non-trivial amount of
>> complexity to our data paths.
> 
> My understanding from the communication with the customer whose reports
> resulted in commits acf8dd0a9d0b ("udp: only allow UFO for packets from
> SOCK_DGRAM sockets") and a5cb659bbc1c ("net: account for current skb
> length when deciding about UFO") was that the real benefit from UFO is 
> in the case when UFO allows to avoid the need to actually fragment the 
> packets. In their case it's when UDP packets are sent via virtio_net 
> either between a guest and its host or between two guests on the same 
> host.
> 
> Personally I have no idea how big the effect is in their use cases so 
> I forwarded the link to your series to them and asked them to provide 
> some real life data if they want to step in. If there is no significant
> performance benefit even in this case, I would agree the feature is not
> worth the hassle - if nothing else, the ever growing list of exceptions
> in ip{,6}_append_data() is getting out of hands.

Thank for letting us know about this.

However, unless the performance gains are significant and there are no
conceivable alternative ways to achieve the same thing, I'm still
removing this.