From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: [PATCH net-next 0/2] allow setting gso_maximum values Date: Fri, 1 Dec 2017 12:11:56 -0800 Message-ID: <20171201201158.25594-1-sthemmin@microsoft.com> Cc: netdev@vger.kernel.org, Stephen Hemminger To: davem@davemloft.net Return-path: Received: from mail-pf0-f194.google.com ([209.85.192.194]:43351 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751089AbdLAUMJ (ORCPT ); Fri, 1 Dec 2017 15:12:09 -0500 Received: by mail-pf0-f194.google.com with SMTP id e3so5100852pfi.10 for ; Fri, 01 Dec 2017 12:12:09 -0800 (PST) Sender: netdev-owner@vger.kernel.org List-ID: 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