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
| ||
|
Date: Sun, 18 Jul 2021 19:51:08 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net> Cc: Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Jiri Pirko <jiri@...nulli.us>, Ido Schimmel <idosch@...sch.org>, Tobias Waldekranz <tobias@...dekranz.com>, Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov <nikolay@...dia.com>, Stephen Hemminger <stephen@...workplumber.org>, bridge@...ts.linux-foundation.org, Grygorii Strashko <grygorii.strashko@...com>, Marek Behun <kabel@...ckhole.sk>, DENG Qingfang <dqfext@...il.com> Subject: Re: [PATCH v4 net-next 13/15] net: dsa: add support for bridge TX forwarding offload On 7/18/2021 2:44 PM, Vladimir Oltean wrote: > For a DSA switch, to offload the forwarding process of a bridge device > means to send the packets coming from the software bridge as data plane > packets. This is contrary to everything that DSA has done so far, > because the current taggers only know to send control packets (ones that > target a specific destination port), whereas data plane packets are > supposed to be forwarded according to the FDB lookup, much like packets > ingressing on any regular ingress port. If the FDB lookup process > returns multiple destination ports (flooding, multicast), then > replication is also handled by the switch hardware - the bridge only > sends a single packet and avoids the skb_clone(). > > DSA plays a substantial role in backing the forwarding offload, and > leaves relatively few things up to the switch driver. In particular, DSA > keeps for each bridge port a zero-based index (the number of the > bridge). Multiple ports enslaved to the same bridge have a pointer to > the same accel_priv structure. > > The tagger can check if the packet that is being transmitted on has > skb->offload_fwd_mark = true or not. If it does, it can be sure that the > packet belongs to the data plane of a bridge, further information about > which can be obtained based on dp->bridge_dev and dp->bridge_num. > It can then compose a DSA tag for injecting a data plane packet into > that bridge number. > > For the switch driver side, we offer two new dsa_switch_ops methods, > called .port_bridge_fwd_offload_{add,del}, which are modeled after > .port_bridge_{join,leave}. > These methods are provided in case the driver needs to configure the > hardware to treat packets coming from that bridge software interface as > data plane packets. The switchdev <-> bridge interaction happens during > the netdev_master_upper_dev_link() call, so to switch drivers, the > effect is that the .port_bridge_fwd_offload_add() method is called > immediately after .port_bridge_join(). > > If the bridge number exceeds the number of bridges for which the switch > driver can offload the TX data plane (and this includes the case where > the driver can offload none), DSA falls back to simply returning > tx_fwd_offload = false in the switchdev_bridge_port_offload() call. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com> > --- Reviewed-by: Florian Fainelli <f.fainelli@...il.com> -- Florian
Powered by blists - more mailing lists