netdev - Re: [PATCH net-next] docs: networking: dpaa2: add documentation for the switch driver

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]

Date:   Thu, 22 Jul 2021 17:42:58 +0300
From:   Ioana Ciornei <ciorneiioana@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Ioana Ciornei <ciorneiioana@...il.com>, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org, corbet@....net,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: [PATCH net-next] docs: networking: dpaa2: add documentation for
 the switch driver

On Thu, Jul 22, 2021 at 04:27:22PM +0200, Andrew Lunn wrote:
> > +At the moment, the dpaa2-switch driver imposes the following restrictions on
> > +the DPSW object that it will probe:
> > +
> > + * The maximum number of FDBs should be at least equal to the number of switch
> > +   interfaces.
> 
> Should maximum actually be minimum?
> 

Uhh, it should have been minimum indeed. Will fix. Thanks!

> This is necessary so that separation of switch ports can be
> > +   done, ie when not under a bridge, each switch port will have its own FDB.
> > +
> > + * Both the broadcast and flooding configuration should be per FDB. This
> > +   enables the driver to restrict the broadcast and flooding domains of each
> > +   FDB depending on the switch ports that are sharing it (aka are under the
> > +   same bridge).
> > +
> > + * The control interface of the switch should not be disabled
> > +   (DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the
> > +   control interface, the driver is not capable to provide proper Rx/Tx traffic
> > +   support on the switch port netdevices.
> > +
> > +Besides the configuration of the actual DPSW object, the dpaa2-switch driver
> > +will need the following DPAA2 objects:
> > +
> > + * 1 DPMCP - A Management Command Portal object is needed for any interraction
> > +   with the MC firmware.
> > +
> > + * 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path
> > +   on the control interface.
> > +
> > + * Access to at least one DPIO object (Software Portal) is needed for any
> > +   enqueue/dequeue operation to be performed on the control interface queues.
> > +   The DPIO object will be shared, no need for a private one.
> 
> Are these requirements tested? Will the driver fail probe if they are
> not met?

Yes, they are tested.

If the DPSW object configuration does not meet the requirements, the
driver will error out on probe with a message explictly saying what
is happening.

> 
> > +Routing actions (redirect, trap, drop)
> > +--------------------------------------
> > +
> > +The DPAA2 switch is able to offload flow-based redirection of packets making
> > +use of ACL tables. Shared filter blocks are supported by sharing a single ACL
> > +table between multiple ports.
> > +
> > +The following flow keys are supported:
> > +
> > + * Ethernet: dst_mac/src_mac
> > + * IPv4: dst_ip/src_ip/ip_proto/tos
> > + * VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei
> > + * L4: dst_port/src_port
> > +
> > +Also, the matchall filter can be used to redirect the entire traffic received
> > +on a port.
> > +
> > +As per flow actions, the following are supported:
> > +
> > + * drop
> > + * mirred egress redirect
> > + * trap
> > +
> > +Each ACL entry (filter) can be setup with only one of the listed
> > +actions.
> > +
> > +A sorted single linked list is used to keep the ACL entries by their
> > +order of priority. When adding a new filter, this enables us to quickly
> > +ascertain if the new entry has the highest priority of the entire block
> > +or if we should make some space in the ACL table by increasing the
> > +priority of the filters already in the table.
> 
> It would be nice to have an example which shows priority in action,
> since i don't understand what you are saying here.
> 

Sure, will add an example.

On the other hand, I think this section might give too much details on
the actual implementation (I took it from the commit message of the
patch adding the support). Might as well just remove it and add the
example.

All that I was trying to say is that the filters will not be added in
the ACL table with the explicit priority specified by the user but
rather with one determined based on all the rules currently present in
the table.
Nothing is unusual in the usage, the order in which the rules are
executed will be respected.

Ioana