| Message ID | 20201111131153.3816-1-tobias@waldekranz.com |
|---|---|
| Headers | show |
| Series | net: dsa: tag_dsa: Unify regular and ethertype DSA taggers | expand |
On Wed, 11 Nov 2020 14:11:52 +0100 Tobias Waldekranz wrote: > Ethertype DSA encodes exactly the same information in the DSA tag as > the non-ethertype variety. So refactor out the common parts and reuse > them for both protocols. > > This is ensures tag parsing and generation is always consistent across > all mv88e6xxx chips. > > While we are at it, explicitly deal with all possible CPU codes on > receive, making sure to set offload_fwd_mark as appropriate. Uncharacteristically unreviewed for a DSA patch :) > + * > + * Regular DSA > + * ----------- > + * For untagged (in 802.1Q terms) packes, the swich will splice in the packes -> packets swich -> switch > + * tag between the SA and the ethertype of the original packet. Tagged > + * frames will instead have their outermost .1Q tag converted to a DSA > + * tag. It expects the same layout when receiving packets from the > + * CPU.
On Fri, Nov 13, 2020 at 04:27:09PM -0800, Jakub Kicinski wrote: > On Wed, 11 Nov 2020 14:11:52 +0100 Tobias Waldekranz wrote: > > Ethertype DSA encodes exactly the same information in the DSA tag as > > the non-ethertype variety. So refactor out the common parts and reuse > > them for both protocols. > > > > This is ensures tag parsing and generation is always consistent across > > all mv88e6xxx chips. > > > > While we are at it, explicitly deal with all possible CPU codes on > > receive, making sure to set offload_fwd_mark as appropriate. > > Uncharacteristically unreviewed for a DSA patch :) Yeah, I don't know what happened...
On Wed, Nov 11, 2020 at 02:11:52PM +0100, Tobias Waldekranz wrote: > Ethertype DSA encodes exactly the same information in the DSA tag as > the non-ethertype variety. So refactor out the common parts and reuse > them for both protocols. > > This is ensures tag parsing and generation is always consistent across > all mv88e6xxx chips. > > While we are at it, explicitly deal with all possible CPU codes on > receive, making sure to set offload_fwd_mark as appropriate. > > Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> > --- Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Hi Tobias > +/** > + * enum dsa_cmd - DSA Command > + * @DSA_CMD_TO_CPU: Set on packets that were trapped or mirrored to > + * the CPU port. This is needed to implement control protocols, > + * e.g. STP and LLDP, that must not allow those control packets to > + * be switched according to the normal rules. Maybe we want to mention that this only makes sense for packets egressing the switch? > + * @DSA_CMD_FROM_CPU: Used by the CPU to send a packet to a specific > + * port, ignoring all the barriers that the switch normally > + * enforces (VLANs, STP port states etc.). "sudo send packet" This only make sense for packets ingressing the switch. The TO_CPU/FROM_CPU kind of make that clear but.. > + * @DSA_CMD_TO_SNIFFER: Set on packets that where mirrored to the CPU > + * as a result of matching some user configured ingress or egress > + * monitor criteria. > + * @DSA_CMD_FORWARD: Everything else, i.e. the bulk data traffic. I assume this can be used in both direction? > + * > + * A 3-bit code is used to relay why a particular frame was sent to > + * the CPU. We only use this to determine if the packet was mirrored > + * or trapped, i.e. whether the packet has been forwarded by hardware > + * or not. Maybe add that, not all generations support all codes. > +static struct sk_buff *dsa_rcv_ll(struct sk_buff *skb, struct net_device *dev, > + u8 extra) > { > + int source_device, source_port; > + enum dsa_code code; > + enum dsa_cmd cmd; > u8 *dsa_header; > - int source_device; > - int source_port; > - > - if (unlikely(!pskb_may_pull(skb, DSA_HLEN))) > - return NULL; > > /* > * The ethertype field is part of the DSA header. > */ > dsa_header = skb->data - 2; > > - /* > - * Check that frame type is either TO_CPU or FORWARD. > - */ > - if ((dsa_header[0] & 0xc0) != 0x00 && (dsa_header[0] & 0xc0) != 0xc0) > + cmd = dsa_header[0] >> 6; > + switch (cmd) { > + case DSA_CMD_FORWARD: > + skb->offload_fwd_mark = 1; > + break; > + > + case DSA_CMD_TO_CPU: > + code = (dsa_header[1] & 0x6) | ((dsa_header[2] >> 4) & 1); > + > + switch (code) { > + case DSA_CODE_FRAME2REG: > + /* Remote management frames originate from the > + * switch itself, there is no DSA port for us > + * to ingress it on (the port field is always > + * 0 in these tags). If/when we get around to implementing this, i doubt we will ingress it like a frame. It will get picked up here and probably added to some queue and a thread woken up. So maybe just say, not implemented yet, so drop it. > + */ > + return NULL; > + case DSA_CODE_ARP_MIRROR: > + case DSA_CODE_POLICY_MIRROR: > + /* Mark mirrored packets to notify any upper > + * device (like a bridge) that forwarding has > + * already been done by hardware. > + */ > + skb->offload_fwd_mark = 1; > + break; > + case DSA_CODE_MGMT_TRAP: > + case DSA_CODE_IGMP_MLD_TRAP: > + case DSA_CODE_POLICY_TRAP: > + /* Traps have, by definition, not been > + * forwarded by hardware, so don't mark them. > + */ Humm, yes, they have not been forwarded by hardware. But is the software bridge going to do the right thing and not flood them? Up until now, i think we did mark them. So this is a clear change in behaviour. I wonder if we want to break this out into a separate patch? If something breaks, we can then bisect was it the combining which broke it, or the change of this mark. I will try to test this on my hardware, but it is probably same as your 6390X and 6352. Andrew
On Sat Nov 14, 2020 at 4:08 AM CET, Andrew Lunn wrote: > Hi Tobias > > > +/** > > + * enum dsa_cmd - DSA Command > > + * @DSA_CMD_TO_CPU: Set on packets that were trapped or mirrored to > > + * the CPU port. This is needed to implement control protocols, > > + * e.g. STP and LLDP, that must not allow those control packets to > > + * be switched according to the normal rules. > > Maybe we want to mention that this only makes sense for packets > egressing the switch? > > > + * @DSA_CMD_FROM_CPU: Used by the CPU to send a packet to a specific > > + * port, ignoring all the barriers that the switch normally > > + * enforces (VLANs, STP port states etc.). "sudo send packet" > > This only make sense for packets ingressing the switch. The > TO_CPU/FROM_CPU kind of make that clear but.. Honestly yes, I think it is pretty clear. But I am happy to change it if you have any particular formulation you would like in there. > > + * @DSA_CMD_TO_SNIFFER: Set on packets that where mirrored to the CPU > > + * as a result of matching some user configured ingress or egress > > + * monitor criteria. > > + * @DSA_CMD_FORWARD: Everything else, i.e. the bulk data traffic. > > I assume this can be used in both direction? Yes. I can add a sentence about that. > > + * > > + * A 3-bit code is used to relay why a particular frame was sent to > > + * the CPU. We only use this to determine if the packet was mirrored > > + * or trapped, i.e. whether the packet has been forwarded by hardware > > + * or not. > > Maybe add that, not all generations support all codes. Not sure I have that information. The oldest chipset I've worked with is Jade (6095/6185) and in that datasheet the TO_CPU tag is not even documented. From Opal+(6097) all the way through Agate, Peridot, and Amethyst, the definitions have not changed from what I can see? > > + /* Remote management frames originate from the > > + * switch itself, there is no DSA port for us > > + * to ingress it on (the port field is always > > + * 0 in these tags). > > If/when we get around to implementing this, i doubt we will ingress it > like a frame. It will get picked up here and probably added to some > queue and a thread woken up. So maybe just say, not implemented yet, > so drop it. v1 actually had a sentence about this :) I can put it back. > > + */ > > + return NULL; > > + case DSA_CODE_ARP_MIRROR: > > + case DSA_CODE_POLICY_MIRROR: > > + /* Mark mirrored packets to notify any upper > > + * device (like a bridge) that forwarding has > > + * already been done by hardware. > > + */ > > + skb->offload_fwd_mark = 1; > > + break; > > + case DSA_CODE_MGMT_TRAP: > > + case DSA_CODE_IGMP_MLD_TRAP: > > + case DSA_CODE_POLICY_TRAP: > > + /* Traps have, by definition, not been > > + * forwarded by hardware, so don't mark them. > > + */ > > Humm, yes, they have not been forwarded by hardware. But is the > software bridge going to do the right thing and not flood them? Up The bridge is free to flood them if it wants to (e.g. IGMP/MLD snooping is off) or not (e.g. IGMP/MLD snooping enabled). The point is, that is not for a lowly switchdev driver to decide. Our job is to relay to the bridge if this skb has been forwarded or not, the end. > until now, i think we did mark them. So this is a clear change in > behaviour. I wonder if we want to break this out into a separate > patch? If something breaks, we can then bisect was it the combining > which broke it, or the change of this mark. Since mv88e6xxx can not configure anything that generates DSA_CODE_MGMT_TRAP or DSA_CODE_POLICY_TRAP yet, we do not have to worry about any change in behavior there. That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem: Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD packets, whereas tag_edsa.c will exempt them. So we can not unify the two without changing the behavior of one. I posit that tag_edsa does the right thing, the packet has not been forwarded, so we should go with that. This is precisely the reason why we want to unify these! :) > I will try to test this on my hardware, but it is probably same as > your 6390X and 6352. Thank you!
On Sat, Nov 14, 2020 at 12:29:32PM +0100, Tobias Waldekranz wrote: > > Humm, yes, they have not been forwarded by hardware. But is the > > software bridge going to do the right thing and not flood them? Up > > The bridge is free to flood them if it wants to (e.g. IGMP/MLD > snooping is off) or not (e.g. IGMP/MLD snooping enabled). The point > is, that is not for a lowly switchdev driver to decide. Our job is to > relay to the bridge if this skb has been forwarded or not, the end. > > > until now, i think we did mark them. So this is a clear change in > > behaviour. I wonder if we want to break this out into a separate > > patch? If something breaks, we can then bisect was it the combining > > which broke it, or the change of this mark. > > Since mv88e6xxx can not configure anything that generates > DSA_CODE_MGMT_TRAP or DSA_CODE_POLICY_TRAP yet, we do not have to > worry about any change in behavior there. > > That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem: > > Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD > packets, whereas tag_edsa.c will exempt them. So we can not unify the > two without changing the behavior of one. > > I posit that tag_edsa does the right thing, the packet has not been > forwarded, so we should go with that. > > This is precisely the reason why we want to unify these! :) Shouldn't the correct approach be to monitor the SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED attribute in order to figure out whether IGMP/MLD snooping is enabled or not?
On Sat Nov 14, 2020 at 3:20 PM CET, Vladimir Oltean wrote: > On Sat, Nov 14, 2020 at 12:29:32PM +0100, Tobias Waldekranz wrote: > > > Humm, yes, they have not been forwarded by hardware. But is the > > > software bridge going to do the right thing and not flood them? Up > > > > The bridge is free to flood them if it wants to (e.g. IGMP/MLD > > snooping is off) or not (e.g. IGMP/MLD snooping enabled). The point > > is, that is not for a lowly switchdev driver to decide. Our job is to > > relay to the bridge if this skb has been forwarded or not, the end. > > > > > until now, i think we did mark them. So this is a clear change in > > > behaviour. I wonder if we want to break this out into a separate > > > patch? If something breaks, we can then bisect was it the combining > > > which broke it, or the change of this mark. > > > > Since mv88e6xxx can not configure anything that generates > > DSA_CODE_MGMT_TRAP or DSA_CODE_POLICY_TRAP yet, we do not have to > > worry about any change in behavior there. > > > > That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem: > > > > Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD > > packets, whereas tag_edsa.c will exempt them. So we can not unify the > > two without changing the behavior of one. > > > > I posit that tag_edsa does the right thing, the packet has not been > > forwarded, so we should go with that. > > > > This is precisely the reason why we want to unify these! :) > > Shouldn't the correct approach be to monitor the > SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED attribute in order to figure out > whether IGMP/MLD snooping is enabled or not? The correct thing is to do both. Independent of wheter IGMP/MLD snooping is statically or dynamically enabled, it is always true that a TO_CPU with code 2 has _never_ been forwarded in hardware and a FORWARD _always_ has been (which is the tag you would see on IGMP frames reaching the CPU in that case). In the static case, we would always get TO_CPUs with code 2, and thus never set offload_fwd_mark. If snooping is enabled on the bridge, they won't be forwarded. If snooping is disabled, the bridge will want to forward, which it can since the mark is not set. In the dynamic case, we would get TO_CPUs with code 2 when snooping is enabled. The mark won't be set, but the bridge does not want to forward anyway. When snooping is disabled, we would get FORWARDs. The bridge will want to forward those, see that the mark is set, and skip it. The only combination that does not work is of course to have snooping permanently _off_ in hardware and expect to use snooping correctly on the software bridge. In that case you would always get FORWARDs, and always set the mark. The bridge will not want to flood, but it is too late since the hardware has already done it.
> > > + * > > > + * A 3-bit code is used to relay why a particular frame was sent to > > > + * the CPU. We only use this to determine if the packet was mirrored > > > + * or trapped, i.e. whether the packet has been forwarded by hardware > > > + * or not. > > > > Maybe add that, not all generations support all codes. > > Not sure I have that information. I'm not asking you list per code which switches support it. I'm just think we should add a warning, it cannot be assumed all switches support all codes. I just looked at the 6161 for example, and it is missing 5 from its list. > > > + */ > > > + return NULL; > > > + case DSA_CODE_ARP_MIRROR: > > > + case DSA_CODE_POLICY_MIRROR: > > > + /* Mark mirrored packets to notify any upper > > > + * device (like a bridge) that forwarding has > > > + * already been done by hardware. > > > + */ > > > + skb->offload_fwd_mark = 1; > > > + break; > > > + case DSA_CODE_MGMT_TRAP: > > > + case DSA_CODE_IGMP_MLD_TRAP: > > > + case DSA_CODE_POLICY_TRAP: > > > + /* Traps have, by definition, not been > > > + * forwarded by hardware, so don't mark them. > > > + */ > > > > Humm, yes, they have not been forwarded by hardware. But is the > > software bridge going to do the right thing and not flood them? Up > > The bridge is free to flood them if it wants to (e.g. IGMP/MLD > snooping is off) or not (e.g. IGMP/MLD snooping enabled). The point > is, that is not for a lowly switchdev driver to decide. Our job is to > relay to the bridge if this skb has been forwarded or not, the end. > > > until now, i think we did mark them. So this is a clear change in > > behaviour. I wonder if we want to break this out into a separate > > patch? If something breaks, we can then bisect was it the combining > > which broke it, or the change of this mark. > > Since mv88e6xxx can not configure anything that generates > DSA_CODE_MGMT_TRAP or DSA_CODE_POLICY_TRAP yet, we do not have to > worry about any change in behavior there. > > That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem: > > Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD > packets, whereas tag_edsa.c will exempt them. So we can not unify the > two without changing the behavior of one. I'm not saying that this change is wrong. I'm just afraid as a behaviour change, it might break something. If something does break, it will be easier to track down, if it is a change on its own. So please look if we can add a simple patch to tag_dsa.c which removes the marking of such frames. And then the next patch can combine the two into one driver. If it does break, git bisect will then tell us which patch broke it. Andrew
On Sat Nov 14, 2020 at 5:44 PM CET, Andrew Lunn wrote: > > > > + * > > > > + * A 3-bit code is used to relay why a particular frame was sent to > > > > + * the CPU. We only use this to determine if the packet was mirrored > > > > + * or trapped, i.e. whether the packet has been forwarded by hardware > > > > + * or not. > > > > > > Maybe add that, not all generations support all codes. > > > > Not sure I have that information. > > I'm not asking you list per code which switches support it. I'm just > think we should add a warning, it cannot be assumed all switches > support all codes. I just looked at the 6161 for example, and it is > missing 5 from its list. I see, yeah sure I can do that. > > That leaves us with DSA_CODE_IGMP_MLD_TRAP. Here is the problem: > > > > Currenly, tag_dsa.c will set skb->offload_fwd_mark for IGMP/MLD > > packets, whereas tag_edsa.c will exempt them. So we can not unify the > > two without changing the behavior of one. > > I'm not saying that this change is wrong. I'm just afraid as a > behaviour change, it might break something. If something does break, > it will be easier to track down, if it is a change on its own. So > please look if we can add a simple patch to tag_dsa.c which removes > the marking of such frames. And then the next patch can combine the > two into one driver. If it does break, git bisect will then tell us > which patch broke it. Ahh, I think I see what you are saying now. So I would copy the IGMP/MLD exemption from tag_edsa.c to tag_dsa.c first, and then apply the unify patch. Yeah that makes alot of sense, will do!