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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ