On Mon, 27 Nov 2017 12:14:19 -0800 Solio Sarabia <solio.sara...@intel.com> wrote:
> On Sun, Nov 26, 2017 at 11:07:25PM -0800, Stephen Hemminger wrote: > > On Sun, 26 Nov 2017 20:13:39 -0700 > > David Ahern <dsah...@gmail.com> wrote: > > > > > On 11/26/17 11:17 AM, Stephen Hemminger wrote: > > > > This allows veth device in containers to see the GSO maximum > > > > settings of the actual device being used for output. > > > > > > veth devices can be added to a VRF instead of a bridge, and I do not > > > believe the gso propagation works for L3 master devices. > > > > > > From a quick grep, team devices do not appear to handle gso changes > > > either. > > > > This code should still work correctly, but no optimization would happen. > > The gso_max_size of the VRF or team will > > still be GSO_MAX_SIZE so there would be no change. If VRF or Team ever got > > smart > > enough to handle GSO limits, then the algorithm would handle it. > > This patch propagates gso value from bridge to its veth endpoints. > However, since bridge is never aware of the GSO limit from underlying > interfaces, bridge/veth still have larger GSO size. > > In the docker case, bridge is not linked directly to physical or > synthetic interfaces; it relies on iptables to decide which interface to > forward packets to. So for the docker case, then direct control of GSO values via netlink (ie ip link set) seems like the better solution.
