Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

[netdev]

On 2022-07-17 17:20, Ido Schimmel wrote:
> On Sun, Jul 17, 2022 at 02:21:47PM +0200, netdev@xxxxxxxxxxxxxxxxxxxx 
> wrote:
> > On 2022-07-13 14:39, Ido Schimmel wrote:
> > > On Wed, Jul 13, 2022 at 09:09:58AM +0200, netdev@xxxxxxxxxxxxxxxxxxxx
> > > 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