From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Frederic Sowa Subject: Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers Date: Tue, 21 Jun 2016 10:40:32 -0700 Message-ID: <234d6a2f-6971-7029-0645-f98e51236c4f@redhat.com> References: <20160616191851.20872.67154.stgit@localhost.localdomain> <20160617.202641.1821023739498595024.davem@davemloft.net> <20160621.042211.945844554759834352.davem@davemloft.net> <18b4d172-2cf5-8246-9cac-ce92adf65bc8@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Tom Herbert , Alex Duyck , Netdev , intel-wired-lan , Jesse Gross , Eugenia Emantayev , Jiri Benc , Saeed Mahameed , Ariel Elior , Michael Chan , Dept-GELinuxNICDev@qlogic.com To: Edward Cree , Alexander Duyck , David Miller Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49421 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752076AbcFURkk (ORCPT ); Tue, 21 Jun 2016 13:40:40 -0400 In-Reply-To: <18b4d172-2cf5-8246-9cac-ce92adf65bc8@solarflare.com> Sender: netdev-owner@vger.kernel.org List-ID: On 21.06.2016 10:27, Edward Cree wrote: > On 21/06/16 18:05, Alexander Duyck wrote: >> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote: >>> But anyways, the vastness of the key is why we want to keep "sockets" >>> out of network cards, because proper support of "sockets" requires >>> access to information the card simply does not and should not have. >> Right. Really what I would like to see for most of these devices is a >> 2 tuple filter where you specify the UDP port number, and the PF/VF ID >> that the traffic is received on. > But that doesn't make sense - the traffic is received on a physical network > port, and it's the headers (i.e. flow) at that point that determine whether > the traffic is encap or not. After all, those headers are all that can > determine which PF or VF it's sent to; and if it's multicast and goes to > more than one of them, it seems odd for one to treat it as encap and the > other to treat it as normal UDP - one of them must be misinterpreting it > (unless the UDP is going to a userspace tunnel endpoint, but I'm ignoring > that complication for now). Disabling offloading of packets is never going to cause data corruptions or misinterpretations. In some cases we can hint the network card to do even more (RSS+checksumming). We always have a safe choice, namely not doing hw offloading. Multicast is often scoped, in some cases we have different multicast scopes but the same addresses. In case of scoped traffic, we must verify the device as well and can't install the same flow on every NIC. > At a given physical point in the network, a given UDP flow either is or is > not carrying encapsulated traffic, and if it tries to be both then things > are certain to break, just as much as if two different applications try to > use the same UDP flow for two different application protocols. I think the example Tom was hinting at initially is like that: A net namespace acts as a router and has a vxlan endpoint active. The vxlan endpoint enables vxlan offloading on all net_devices in the same namespace. Because we only identify the tunnel endpoint by UDP port number, traffic which should actually just be forwarded and should never be processed locally suddenly can become processed by the offloading hw units. Because UDP ports only form a contract between the end points and not with the router in between it would be illegal to treat those not locally designated packets as vxlan by the router. Also multicast traffic is always scoped, so the flow has to include the ifindex at least to allow differentiation between different scopes. Bye, Hannes From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Frederic Sowa Date: Tue, 21 Jun 2016 10:40:32 -0700 Subject: [Intel-wired-lan] [net-next PATCH v3 00/17] Future-proof tunnel offload handlers In-Reply-To: <18b4d172-2cf5-8246-9cac-ce92adf65bc8@solarflare.com> References: <20160616191851.20872.67154.stgit@localhost.localdomain> <20160617.202641.1821023739498595024.davem@davemloft.net> <20160621.042211.945844554759834352.davem@davemloft.net> <18b4d172-2cf5-8246-9cac-ce92adf65bc8@solarflare.com> Message-ID: <234d6a2f-6971-7029-0645-f98e51236c4f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On 21.06.2016 10:27, Edward Cree wrote: > On 21/06/16 18:05, Alexander Duyck wrote: >> On Tue, Jun 21, 2016 at 1:22 AM, David Miller wrote: >>> But anyways, the vastness of the key is why we want to keep "sockets" >>> out of network cards, because proper support of "sockets" requires >>> access to information the card simply does not and should not have. >> Right. Really what I would like to see for most of these devices is a >> 2 tuple filter where you specify the UDP port number, and the PF/VF ID >> that the traffic is received on. > But that doesn't make sense - the traffic is received on a physical network > port, and it's the headers (i.e. flow) at that point that determine whether > the traffic is encap or not. After all, those headers are all that can > determine which PF or VF it's sent to; and if it's multicast and goes to > more than one of them, it seems odd for one to treat it as encap and the > other to treat it as normal UDP - one of them must be misinterpreting it > (unless the UDP is going to a userspace tunnel endpoint, but I'm ignoring > that complication for now). Disabling offloading of packets is never going to cause data corruptions or misinterpretations. In some cases we can hint the network card to do even more (RSS+checksumming). We always have a safe choice, namely not doing hw offloading. Multicast is often scoped, in some cases we have different multicast scopes but the same addresses. In case of scoped traffic, we must verify the device as well and can't install the same flow on every NIC. > At a given physical point in the network, a given UDP flow either is or is > not carrying encapsulated traffic, and if it tries to be both then things > are certain to break, just as much as if two different applications try to > use the same UDP flow for two different application protocols. I think the example Tom was hinting at initially is like that: A net namespace acts as a router and has a vxlan endpoint active. The vxlan endpoint enables vxlan offloading on all net_devices in the same namespace. Because we only identify the tunnel endpoint by UDP port number, traffic which should actually just be forwarded and should never be processed locally suddenly can become processed by the offloading hw units. Because UDP ports only form a contract between the end points and not with the router in between it would be illegal to treat those not locally designated packets as vxlan by the router. Also multicast traffic is always scoped, so the flow has to include the ifindex at least to allow differentiation between different scopes. Bye, Hannes