netdev - [PATCH net-next 0/2] allow setting gso

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20171201201158.25594-1-sthemmin@microsoft.com>
Date:   Fri,  1 Dec 2017 12:11:56 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     davem@...emloft.net
Cc:     netdev@...r.kernel.org, Stephen Hemminger <sthemmin@...rosoft.com>
Subject: [PATCH net-next 0/2] allow setting gso_maximum values

This is another way of addressing the GSO maximum performance issues for
containers on Azure. What happens is that the underlying infrastructure uses
a overlay network such that GSO packets over 64K - vlan header end up cause
either guest or host to have do expensive software copy and fragmentation.

The netvsc driver reports GSO maximum settings correctly, the issue
is that containers on veth devices still have the larger settings.
One solution that was examined was propogating the values back
through the bridge device, but this does not work for cases where
virtual container network is done on L3.

This patch set punts the problem to the orchestration layer that sets
up the container network. It also enables other virtual devices
to have configurable settings for GSO maximum.

Stephen Hemminger (2):
  rtnetlink: allow GSO maximums to be passed to device
  veth: allow configuring GSO maximums

 drivers/net/veth.c   | 20 ++++++++++++++++++++
 net/core/rtnetlink.c |  2 ++
 2 files changed, 22 insertions(+)

-- 
2.11.0