[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20190806.142439.750986288608590840.davem@davemloft.net>
Date: Tue, 06 Aug 2019 14:24:39 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: john.hurley@...ronome.com
Cc: netdev@...r.kernel.org, simon.horman@...ronome.com,
jakub.kicinski@...ronome.com, oss-drivers@...ronome.com
Subject: Re: [PATCH net-next 00/10] Support tunnels over VLAN in NFP
From: John Hurley <john.hurley@...ronome.com>
Date: Sun, 4 Aug 2019 16:09:02 +0100
> This patchset deals with tunnel encap and decap when the end-point IP
> address is on an internal port (for example and OvS VLAN port). Tunnel
> encap without VLAN is already supported in the NFP driver. This patchset
> extends that to include a push VLAN along with tunnel header push.
>
> Patches 1-4 extend the flow_offload IR API to include actions that use
> skbedit to set the ptype of an SKB and that send a packet to port ingress
> from the act_mirred module. Such actions are used in flower rules that
> forward tunnel packets to internal ports where they can be decapsulated.
> OvS and its TC API is an example of a user-space app that produces such
> rules.
>
> Patch 5 modifies the encap offload code to allow the pushing of a VLAN
> header after a tunnel header push.
>
> Patches 6-10 deal with tunnel decap when the end-point is on an internal
> port. They detect 'pre-tunnel rules' which do not deal with tunnels
> themselves but, rather, forward packets to internal ports where they
> can be decapped if required. Such rules are offloaded to a table in HW
> along with an indication of whether packets need to be passed to this
> table of not (based on their destination MAC address). Matching against
> this table prior to decapsulation in HW allows the correct parsing and
> handling of outer VLANs on tunnelled packets and the correct updating of
> stats for said 'pre-tunnel' rules.
Series applied, thanks John.
Powered by blists - more mailing lists