Linux Ethernet Bridging - Jul 2022 - [Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

On 2022-07-17 17:20, Ido Schimmel wrote:
> On Sun, Jul 17, 2022 at 02:21:47PM +0200, netdev at kapio-technology.com 
> wrote:
>> On 2022-07-13 14:39, Ido Schimmel wrote:
>> > On Wed, Jul 13, 2022 at 09:09:58AM +0200, netdev at
kapio-technology.com
>> > wrote:
>> 
>> >
>> > What are "Storm Prevention" and "zero-DPV" FDB
entries?
>> 
>> They are both FDB entries that at the HW level drops all packets 
>> having a
>> specific SA, thus using minimum resources.
>> (thus the name "Storm Prevention" aka, protection against DOS
attacks.
>> We
>> must remember that we operate with CPU based learning.)
>> 
>> >
>> > There is no decision that I'm aware of. I'm simply trying
to understand
>> > how FDB entries that have 'BR_FDB_ENTRY_LOCKED' set are
handled in
>> > mv88e6xxx and other devices in this class. We have at least three
>> > different implementations to consolidate:
>> >
>> > 1. The bridge driver, pure software forwarding. The locked entry
is
>> > dynamically created by the bridge. Packets received via the locked
port
>> > with a SA corresponding to the locked entry will be dropped, but
will
>> > refresh the entry. On the other hand, packets with a DA
corresponding to
>> > the locked entry will be forwarded as known unicast through the
locked
>> > port.
>> >
>> > 2. Hardware implementations like Spectrum that can be programmed
to trap
>> > packets that incurred an FDB miss. Like in the first case, the
locked
>> > entry is dynamically created by the bridge driver and also aged by
it.
>> > Unlike in the first case, since this entry is not present in
hardware,
>> > packets with a DA corresponding to the locked entry will be
flooded as
>> > unknown unicast.
>> >
>> > 3. Hardware implementations like mv88e6xxx that fire an interrupt
upon
>> > FDB miss. Need your help to understand how the above works there
and
>> > why. Specifically, how locked entries are represented in hardware
(if at
>> > all) and what is the significance of not installing corresponding
>> > entries in hardware.
>> >
>> 
>> With the mv88e6xxx, a miss violation with the SA occurs when there is 
>> no
>> entry. If you then add a normal entry with the SA, the port is open 
>> for that
>> SA of course.
> 
> Good
> 
>> The zero-DPV entry is an entry that ensures that there is no more miss
>> violation interrupts from that SA, while dropping all entries with the
>> SA.
> 
> Few questions:
> 
> 1. Is it correct to think of this entry as an entry pointing to a
> special /dev/null port?
I guess you can think of it like that. It's internal to the chipset how 
it does it.
> 
> 2. After installing this entry, you no longer get miss violation
> interrupts because packets with this SA incur a mismatch violation
> (src_port != /dev/null) and therefore discarded in hardware?
Yes, and mismatch violations are suppressed in this implementation when 
locking the port.
> 
> 3. What happens to packets with a DA matching the zero-DPV entry, are
> they also discarded in hardware? If so, here we differ from the bridge
> driver implementation where such packets will be forwarded according to
> the locked entry and egress the locked port
I understand that egress will follow what is setup with regard to UC, MC 
and BC, though I haven't tested that. But no replies will get through of 
course as long as the port hasn't been opened for the iface behind the 
locked port.
> 
> 4. The reason for installing this entry is to suppress further miss
> violation interrupts?
Yes, while still HW dropping all ingress packets with the same (SA-mac, 
vlan) on  the port.
> 
> 5. If not replaced, will this entry always age out after the ageing
> time? Not sure what can refresh it given that traffic does not ingress
> from the /dev/null port.
That is where my implementation keeps the entries in a list and removes 
them after the bridge timeout using a kernel worker and jiffies.
So by default they age out after approx. 5 min.
> 
> Thanks

On Sun, Jul 17, 2022 at 05:53:22PM +0200, netdev at kapio-technology.com
wrote:
> > 3. What happens to packets with a DA matching the zero-DPV entry, are
> > they also discarded in hardware? If so, here we differ from the bridge
> > driver implementation where such packets will be forwarded according
to
> > the locked entry and egress the locked port
> 
> I understand that egress will follow what is setup with regard to UC, MC
and
> BC, though I haven't tested that. But no replies will get through of
course
> as long as the port hasn't been opened for the iface behind the locked
port.
Here, should we be rather fixing the software bridge, if the current
behavior is to forward packets towards locked FDB entries?

On 2022-07-21 13:59, Vladimir Oltean wrote:
> On Sun, Jul 17, 2022 at 05:53:22PM +0200, netdev at kapio-technology.com 
> wrote:
>> > 3. What happens to packets with a DA matching the zero-DPV entry,
are
>> > they also discarded in hardware? If so, here we differ from the
bridge
>> > driver implementation where such packets will be forwarded
according to
>> > the locked entry and egress the locked port
>> 
>> I understand that egress will follow what is setup with regard to UC, 
>> MC and
>> BC, though I haven't tested that. But no replies will get through
of
>> course
>> as long as the port hasn't been opened for the iface behind the
locked
>> port.
> 
> Here, should we be rather fixing the software bridge, if the current
> behavior is to forward packets towards locked FDB entries?
Yes, I think that locked entries should block egress to the respective 
hosts behind the locked port, which should be fixed in the bridge.