On Thu, Nov 30, 2017 at 9:11 AM, Stephen Hemminger <step...@networkplumber.org> wrote: > On Thu, 30 Nov 2017 10:47:21 -0500 (EST) > David Miller <da...@davemloft.net> wrote: > >> From: Stephen Hemminger <step...@networkplumber.org> >> Date: Sun, 26 Nov 2017 10:17:47 -0800 >> >> > This pair of patchesimproves the performance when running >> > containers in an environment where underlying device has lower >> > GSO maximum (such as Azure). >> > >> > With containers a veth pair is created and one end is attached >> > to the bridge device. The bridge device correctly reports >> > computes GSO parameters that are the minimum of the lower devices. >> > >> > The problem is that the other end of the veth device (in container) >> > reports the full GSO size. This patch propogates the upper >> > (bridge device) parameters to the other end of the veth device. >> > >> > Please consider it as alternative to the sysfs GSO changes. >> >> I like this approach a lot, please resubmit this formally. > > Will do and add netif_needs_gso check as well.
Would it make sense to look at possibly moving something like this over to being handled by something like GSO_PARTIAL? Essentially it is the same type of issue where we are needing to split a TSO frame into smaller TSO frames. We already did something like this for the GRO with skb->fraglist case, I wonder if it wouldn't make sense to just handle the oversized GSO the same way. It seems like you could just split add a check against the size and tweak the mss at the start of skb_segment and that should be about all you need to do to take care of it. If I am not mistaken we could probably just tweak the one line that was computing "partial_segs" in skb_segment so that we did something like "partial_segs = min(len, dev->gso_max_size) / mss". This way we take care of the issue for things like GRO as well which doesn't take the max size into account last I knew, and you would still get most of the benefits of TSO. - Alex
