netdev - Re: [PATCH net-next v2 00/12][pull request] ice: switchdev bridge offload

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: <ee09ecbc-b122-391c-bbf1-936c9b105192@intel.com>
Date: Wed, 26 Jul 2023 14:01:25 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Vlad Buslov <vladbu@...dia.com>, Tony Nguyen <anthony.l.nguyen@...el.com>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <netdev@...r.kernel.org>, <wojciech.drewek@...el.com>,
	<jiri@...nulli.us>, <ivecera@...hat.com>, <simon.horman@...igine.com>
Subject: Re: [PATCH net-next v2 00/12][pull request] ice: switchdev bridge
 offload



On 7/25/2023 12:32 PM, Vlad Buslov wrote:
> On Mon 24 Jul 2023 at 09:11, Tony Nguyen <anthony.l.nguyen@...el.com> wrote:
>> Wojciech Drewek says:
>>
>> Linux bridge provides ability to learn MAC addresses and vlans
>> detected on bridge's ports. As a result of this, FDB (forward data base)
>> entries are created and they can be offloaded to the HW. By adding
>> VF's port representors to the bridge together with the uplink netdev,
>> we can learn VF's and link partner's MAC addresses. This is achieved
>> by slow/exception-path, where packets that do not match any filters
>> (FDB entries in this case) are send to the bridge ports.
>>
>> Driver keeps track of the netdevs added to the bridge
>> by listening for NETDEV_CHANGEUPPER event. We distinguish two types
>> of bridge ports: uplink port and VF's representor port. Linux
>> bridge always learns src MAC of the packet on rx path. With the
>> current slow-path implementation, it means that we will learn
>> VF's MAC on port repr (when the VF transmits the packet) and
>> link partner's MAC on uplink (when we receive it on uplink from LAN).
>>
>> The driver is notified about learning of the MAC/VLAN by
>> SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation
>> of the HW filter. The direction of the filter is based on port
>> type (uplink or VF repr). In case of the uplink, rule forwards
>> the packets to the LAN (matching on link partner's MAC). When the
>> notification is received on VF repr then the rule forwards the
>> packets to the associated VF (matching on VF's MAC).
>>
>> This approach would not work on its own however. This is because if
>> one of the directions is offloaded, then the bridge would not be able
>> to learn the other one. If the egress rule is added (learned on uplink)
>> then the response from the VF will be sent directly to the LAN.
>> The packet will not got through slow-path, it would not be seen on
>> VF's port repr. Because of that, the bridge would not learn VF's MAC.
>>
>> This is solved by introducing guard rule. It prevents forward rule from
>> working until the opposite direction is offloaded.
>>
>> Aging is not fully supported yet, aging time is static for now. The
>> follow up submissions will introduce counters that will allow us to
>> keep track if the rule is actually being used or not.
>>
>> A few fixes/changes are needed for this feature to work with ice driver.
>> These are introduced in first 5 patches.
>>
>> Reviewed-by: Vlad Buslov <vladbu@...dia.com>
> 
> In my previous reply I meant reviewed-by for the whole series, not for
> the cover letter specifically. Sorry for not being more clear!
> 

For what its worth, it was my understanding that posting a "Reviewed-by"
to the cover letter for the series implies that you reviewed and have no
further comments to the whole series. I don't think you did anything
wrong here :)

Thanks,
Jake