netdev - Re: [RFC net-next 2/6] driver: net: bonding: allow registration of tc offload callbacks in bond

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]

Date:   Wed, 14 Mar 2018 13:23:59 +0200
From:   Or Gerlitz <gerlitz.or@...il.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jiri Pirko <jiri@...lanox.com>, Rabie Loulou <rabiel@...lanox.com>,
        John Hurley <john.hurley@...ronome.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        ASAP_Direct_Dev@...lanox.com, mlxsw <mlxsw@...lanox.com>
Subject: Re: [RFC net-next 2/6] driver: net: bonding: allow registration of tc
 offload callbacks in bond

On Wed, Mar 14, 2018 at 11:50 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> Tue, Mar 13, 2018 at 04:51:02PM CET, gerlitz.or@...il.com wrote:
>>On Wed, Mar 7, 2018 at 12:57 PM, Jiri Pirko <jiri@...nulli.us> wrote:

>>This sounds nice for the case where one install ingress tc rules on
>>the bond (lets
>>call them type 1, see next)
>>
>>One obstacle pointed by my colleague, Rabie, is that when the upper layer
>>issues stat call on the filter, they will get two replies, this can confuse them
>>and lead to wrong decisions (aging). I wonder if/how we can set a knob
>
> The bonding itself would not do anything on stats update
> command (TC_CLSFLOWER_STATS for example). Only the slaves would do
> update. So there will be only reply from slaves.
>
> Bond/team is just going to probagare block bind/unbind down. Nothing else.

Do we agree that user space will get the replies of all lower (slave) devices,
or I am missing something here?

>>2. bond being egress port of a rule
>>2.1 VF rep --> uplink 0
>>2.2 VF rep --> uplink 1
>>
>>and we do that in the driver (add/del two HW rules, combine the stat
>>results, etc)
>
> That is up to the driver. If the driver can share block between 2
> devices, he can do that. If he cannot share, it will just report stats
> for every device separatelly (2 block cbs registered) and tc will see
> them both together. No need to do anything in driver.

right

>>3. ingress rule on VF rep port with shared tunnel device being the
>>egress (encap)
>>and where the routing of the underlay (tunnel) goes through LAG.

> Same as "2."

ok

>>4. ingress rule shared tunnel device being the ingress and VF rep port
>>being the egress (decap)

> I don't follow :(

the way tunneling is handled in tc classifier/action is

encap:  ingress: net port, action1: tunnel key set action2: mirred to
shared-tunnel device

decap: ingress: shared tunnel device, action1: tunnel key unset
action2: mirred to net port

type 4 are the decap rules, when we offload it to as HW ACL we stretch
the line and the ingress
in a HW port too (e.g uplink port in NICs)


>>this uses the egdev facility to be offloaded into the our driver, and
>>then in the driver
>>we will treat it like type 1, two rules need to be installed into HW,
>>but now, we can't delegate them
>>from the vxlan device b/c it has no direct connection with the bond.

> I see another thing we need to sanitize: vxlan rule ingress match action
> mirred redirect to lag

right, we don't have  for NIC but for switch ASIC, I guess it is applicable