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]

Message-ID: <YPmASiX46tOjUOe/@lunn.ch>
Date:   Thu, 22 Jul 2021 16:27:22 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ioana Ciornei <ciorneiioana@...il.com>
Cc:     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

> +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?

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?

> +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.

      Andrew