linux-kernel - Re: [net-next v5 2/3] net: ethernet: adi: Add ADIN1110 support

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: <20220825090842.24c5bc7f@kernel.org>
Date:   Thu, 25 Aug 2022 09:08:42 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     andrei.tachici@...d.acs.upb.ro
Cc:     andrew@...n.ch, davem@...emloft.net, devicetree@...r.kernel.org,
        edumazet@...gle.com, hkallweit1@...il.com, joel@....id.au,
        krzysztof.kozlowski+dt@...aro.org, l.stelmach@...sung.com,
        linux-kernel@...r.kernel.org, linux@...linux.org.uk,
        netdev@...r.kernel.org, pabeni@...hat.com, robh+dt@...nel.org,
        vegard.nossum@...cle.com, vladimir.oltean@....com
Subject: Re: [net-next v5 2/3] net: ethernet: adi: Add ADIN1110 support

On Thu, 25 Aug 2022 13:55:17 +0300 andrei.tachici@...d.acs.upb.ro wrote:
> > I thought this is a callback for legacy SR-IOV NICs. What are you using
> > it for in a HW device over SPI? :S  
> 
> Here I wanted to allow the user to change between VEPA/VEB. The ADIN2111 switch
> is not VLAN aware and also can't do any meaningful forwarding when multiple
> ports from multiple ADIN2111 switches are added to the same software bridge. For these
> cases I thought the user would like to disable hardware forwarding (VEB).

VEPA/VEB is only for traffic originating on the host, it's sort of
inverse of what you're doing. In SR-IOV host has "multiple ports"
not the device. So the question is whether the device punts the packets
produced by the host to the network or tries to switch them internally.
In the former case the connected switch must support hair-pinning the
traffic.

A completely different kettle of fish that "should I forward between
two external ports".

> Should detect the above cases and automatically disable any forwarding instead?

Bridge offloading experts would have to help us out regarding what
other drivers do, I'd think that offload for a bridge straddling
multiple ASICs should still be possible. You can program the forwarding
based on the FDB of the host.

> Hardware forwarding translates to: I don't know this MAC address (not my MAC address)
> throw it back to the other port. ADIN2111 can't learn the FDB, although has 16 entries that
> can be statically programmed.

Do the 16 entries control forwarding (ie. allow you to decide forward
to other port vs forward to host)? Or just trap the packets that match
to the host?