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]

Message-ID: <20180314155640.GF2130@nanopsycho>
Date:   Wed, 14 Mar 2018 16:56:40 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Or Gerlitz <gerlitz.or@...il.com>
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

Wed, Mar 14, 2018 at 12:23:59PM CET, gerlitz.or@...il.com wrote:
>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?

"user space will get the replies" - not sure what exactly do you mean by
this. The stats would be accumulated over all devices/drivers who
registered block callback.


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

Okay, I see. But where's the bond here? Is it the one I mentioned as
"mirred redirect to lag"?


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

Yes, it is. For future NICs I guess it is going to be as well.