[PATCH v2 RFC 0/13] Remove UDP Fragmentation Offload support

[PATCH v2 RFC 0/13] Remove UDP Fragmentation Offload support

[David Miller]

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.

v2: Delete more code thanks to feedback from Willem.

Signed-off-by: David S. Miller <davem@davemloft.net>

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

[Michal Kubecek]

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.

                                                         Michal Kubecek

RE: [PATCH v2 RFC 0/13] Remove UDP Fragmentation Offload support

[David Laight]

From: Michal Kubecek
> Sent: 07 July 2017 13:46
> 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.
> ...

Could that be done with a large path-specific mtu?

	David

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

[David Miller]

From: Michal Kubecek <mkubecek@suse.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.

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

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Fri, 07 Jul 2017 10:43:26 +0100 (WEST)

> 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.
> 
> v2: Delete more code thanks to feedback from Willem.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>

This is now committed to net-next.

Florian, I made good on my dessert eating promise, ok? :-)