forked from Minki/linux
f7cf972f93
Before this change, four related - but distinct - concepts where named
offload_fwd_mark:
- skb->offload_fwd_mark: Set by the switchdev driver if the underlying
hardware has already forwarded this frame to the other ports in the
same hardware domain.
- nbp->offload_fwd_mark: An idetifier used to group ports that share
the same hardware forwarding domain.
- br->offload_fwd_mark: Counter used to make sure that unique IDs are
used in cases where a bridge contains ports from multiple hardware
domains.
- skb->cb->offload_fwd_mark: The hardware domain on which the frame
ingressed and was forwarded.
Introduce the term "hardware forwarding domain" ("hwdom") in the
bridge to denote a set of ports with the following property:
If an skb with skb->offload_fwd_mark set, is received on a port
belonging to hwdom N, that frame has already been forwarded to all
other ports in hwdom N.
By decoupling the name from "offload_fwd_mark", we can extend the
term's definition in the future - e.g. to add constraints that
describe expected egress behavior - without overloading the meaning of
"offload_fwd_mark".
- nbp->offload_fwd_mark thus becomes nbp->hwdom.
- br->offload_fwd_mark becomes br->last_hwdom.
- skb->cb->offload_fwd_mark becomes skb->cb->src_hwdom. The slight
change in naming here mandates a slight change in behavior of the
nbp_switchdev_frame_mark() function. Previously, it only set this
value in skb->cb for packets with skb->offload_fwd_mark true (ones
which were forwarded in hardware). Whereas now we always track the
incoming hwdom for all packets coming from a switchdev (even for the
packets which weren't forwarded in hardware, such as STP BPDUs, IGMP
reports etc). As all uses of skb->cb->offload_fwd_mark were already
gated behind checks of skb->offload_fwd_mark, this will not introduce
any functional change, but it paves the way for future changes where
the ingressing hwdom must be known for frames coming from a switchdev
regardless of whether they were forwarded in hardware or not
(basically, if the skb comes from a switchdev, skb->cb->src_hwdom now
always tracks which one).
A typical example where this is relevant: the switchdev has a fixed
configuration to trap STP BPDUs, but STP is not running on the bridge
and the group_fwd_mask allows them to be forwarded. Say we have this
setup:
br0
/ | \
/ | \
swp0 swp1 swp2
A BPDU comes in on swp0 and is trapped to the CPU; the driver does not
set skb->offload_fwd_mark. The bridge determines that the frame should
be forwarded to swp{1,2}. It is imperative that forward offloading is
_not_ allowed in this case, as the source hwdom is already "poisoned".
Recording the source hwdom allows this case to be handled properly.
v2->v3: added code comments
v3->v6: none
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||
|---|---|---|
| .. | ||
| netfilter | ||
| br_arp_nd_proxy.c | ||
| br_cfm_netlink.c | ||
| br_cfm.c | ||
| br_device.c | ||
| br_fdb.c | ||
| br_forward.c | ||
| br_if.c | ||
| br_input.c | ||
| br_ioctl.c | ||
| br_mdb.c | ||
| br_mrp_netlink.c | ||
| br_mrp_switchdev.c | ||
| br_mrp.c | ||
| br_multicast_eht.c | ||
| br_multicast.c | ||
| br_netfilter_hooks.c | ||
| br_netfilter_ipv6.c | ||
| br_netlink_tunnel.c | ||
| br_netlink.c | ||
| br_nf_core.c | ||
| br_private_cfm.h | ||
| br_private_mcast_eht.h | ||
| br_private_mrp.h | ||
| br_private_stp.h | ||
| br_private_tunnel.h | ||
| br_private.h | ||
| br_stp_bpdu.c | ||
| br_stp_if.c | ||
| br_stp_timer.c | ||
| br_stp.c | ||
| br_switchdev.c | ||
| br_sysfs_br.c | ||
| br_sysfs_if.c | ||
| br_vlan_options.c | ||
| br_vlan_tunnel.c | ||
| br_vlan.c | ||
| br.c | ||
| Kconfig | ||
| Makefile | ||