Messages in this thread | | | Subject | Re: [PATCH net-next 2/2] net: dsa: lan9303: Clear offload_fwd_mark for IGMP | From | Egil Hjelmeland <> | Date | Mon, 13 Nov 2017 12:00:17 +0100 |
| |
On 10. nov. 2017 12:54, Egil Hjelmeland wrote: > Now that IGMP packets no longer is flooded in HW, we want the SW bridge to > forward packets based on bridge configuration. To make that happen, > IGMP packets must have skb->offload_fwd_mark = 0. > > Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no> > --- > net/dsa/tag_lan9303.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/net/dsa/tag_lan9303.c b/net/dsa/tag_lan9303.c > index 5ba01fc3c6ba..b8c5e52b2eff 100644 > --- a/net/dsa/tag_lan9303.c > +++ b/net/dsa/tag_lan9303.c > @@ -92,6 +92,8 @@ static struct sk_buff *lan9303_rcv(struct sk_buff *skb, struct net_device *dev, > { > u16 *lan9303_tag; > unsigned int source_port; > + u16 ether_type_nw; > + u8 ip_protocol; > > if (unlikely(!pskb_may_pull(skb, LAN9303_TAG_LEN))) { > dev_warn_ratelimited(&dev->dev, > @@ -129,6 +131,17 @@ static struct sk_buff *lan9303_rcv(struct sk_buff *skb, struct net_device *dev, > skb->offload_fwd_mark = !ether_addr_equal(skb->data - ETH_HLEN, > eth_stp_addr); > > + /* We also need IGMP packets to have skb->offload_fwd_mark = 0. > + * Solving this for all conceivable situations would add more cost to > + * every packet. Instead we handle just the common case: > + * No VLAN tag + Ethernet II framing. > + * Test least probable term first. > + */ > + ether_type_nw = lan9303_tag[2]; > + ip_protocol = *(skb->data + 9); > + if (ip_protocol == IPPROTO_IGMP && ether_type_nw == htons(ETH_P_IP)) > + skb->offload_fwd_mark = 0; > + > return skb; > } > >
RTFM, my bad. The lan9303 has both STP and IGMP bits in the receive tag. It is as simple as:
u16 lan9303_tag1 = ntohs(lan9303_tag[1]); skb->offload_fwd_mark = !(lan9303_tag1 & 0x18);
Egil
| |