netdev - Re: [PATCH 0/6] offload Linux LAG devices to the TC datapath

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ3xEMg=UDooJtZ4amhJAF1ohHHzLFm7qgWrrkhMmff3G-RstQ@mail.gmail.com>
Date:   Wed, 27 Jun 2018 23:07:29 +0300
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Or Gerlitz <ogerlitz@...lanox.com>,
        John Hurley <john.hurley@...ronome.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        ASAP_Direct_Dev <ASAP_Direct_Dev@...lanox.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Andy Gospodarek <gospo@...adcom.com>
Subject: Re: [PATCH 0/6] offload Linux LAG devices to the TC datapath

On Wed, Jun 27, 2018 at 1:31 AM, Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
> On Tue, 26 Jun 2018 17:57:08 +0300, Or Gerlitz wrote:

>> 2. re the egress side of things. Some NIC HWs can't just use LAG
>> as the egress port destination of an ACL (tc rule) and the HW rule
>> needs to be duplicated to both HW ports. So... in that case, you
>> see the HW driver doing the duplication (:() or we can somehow
>> make it happen from user-space?

> It's the TC core that does the duplication.  Drivers which don't need
> the duplication (e.g. mlxsw) will not register a new callback for each
> port on which shared block is bound.  They will keep one list of rules,
> and a list of ports that those rules apply to.

[snip]

> Drivers which need duplication (multiplication) (all NICs?) have to
> register a new callback for each port bound to a shared block.  And TC
> will call those drivers as many times as they have callbacks registered
> == as many times as they have ports bound to the block.  Each time
> callback is invoked the driver will figure out the ingress port based
> on the cb_priv and use <ingress, cookie> as the key in its rule table
> (or have a separate rule table per ingress port).

[snip snip]

> I may be wrong, but I think you split the rules tables per port for mlx5

correct,  currently I have a rule table per physical port.

> So again you just register a callback every time shared block is bound,
> and then TC core will send add/remove rule commands down to the driver,
> relaying existing rules as well if needed.

Let's see, the NIC uplink rep port devices were bounded (say) by ovs to
a shared-block because they are the lower devices (hate the slavish jargon)
of a bond device.

Next, the TC stack will invoke the callback over these ports, when ingress
rule is added on the bond.

But we are talking on ingress rule set on a non-uplink rep (VF rep) port,
where bonding is the egress of the rule. I guess the callback which you probably
refer to (you hinted there below) is the egdev one, correct? you are suggesting
that bonding will do egdev registration... I am a bit confused.

> Does that clarify things or were you asking more about the active
> passive thing John mentioned or some way to save rule space?

no (didn't refer to active-passive) and no (didn't look to save rule space)
yes for active-active in a HW that needs duplicated rules (NICs).

>> 3. for the case of overlay networks, e.g OVS based vxlan tunnel, the
>> ingress (decap) rule is set on the vxlan device. Jakub, you mentioned
>> a possible kernel patch to the HW (nfp, mlx5) drivers to have them bind
>> to the tunnel device for ingress rules. If we have agreed way to identify
>> uplink representors, can we do that from ovs too?
>
> I'm not sure, there can be multiple tunnel devices.  Plus we really
> want to know the tunnel type, e.g. vxlan vs geneve, so simple shared
> block propagation will probably not cut it.  If that's what you're
> referring to.

isn't knowing the tunnel type already missing today? I saw you
started patches the tunnel key set action for Geneve, does upstream
+ the patches you sent works or more is missing to get geneve encap
through the TC stack?

>> does it matter if we are bonding + encapsulating or just
>> encapsulating? note that under encap scheme the bond is typically not
>> part of the OVS bridge.

> I don't think that matters in general, driver doing bonding offload
> should just start recognizing the bond master as "their port" and
> register an egdev callback for redirects to master today (or equivalent
> in the new scheme once that materializes...)