Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-13 Thread Ido Schimmel via Bridge
On Thu, May 12, 2022 at 10:38:03PM +0200, Andrew Lunn wrote: > > I like Andrew's patch because it is the Rx equivalent of > > br_switchdev_frame_unmark() in br_dev_xmit(). However, if we go with the > > second option, it should allow us to remove the clearing of the mark in > > the Tx path as the c

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-12 Thread Andrew Lunn
> I like Andrew's patch because it is the Rx equivalent of > br_switchdev_frame_unmark() in br_dev_xmit(). However, if we go with the > second option, it should allow us to remove the clearing of the mark in > the Tx path as the control block is cleared in the Tx path since commit > fd65e5a95d08 ("

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-09 Thread Ido Schimmel via Bridge
On Fri, May 06, 2022 at 02:36:45PM +, Vladimir Oltean wrote: > Hi Andrew, > > On Fri, May 06, 2022 at 12:59:04AM +0200, Andrew Lunn wrote: > > It is possible to stack bridges on top of each other. Consider the > > following which makes use of an Ethernet switch: > > > >br1 > > /

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-06 Thread Andrew Lunn
> Some safer alternatives to this patch are based on the idea that we > could ignore skb->offload_fwd_mark coming from an unoffloaded bridge > port (i.e. treat this condition at br1, not at br0). We could: > - clear skb->offload_fwd_mark in br_handle_frame_finish(), if p->hwdom is 0 > - change nbp_

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-06 Thread Stephen Hemminger
On Fri, 6 May 2022 03:18:22 +0200 Andrew Lunn wrote: > On Thu, May 05, 2022 at 04:07:20PM -0700, Stephen Hemminger wrote: > > On Fri, 6 May 2022 00:59:04 +0200 > > Andrew Lunn wrote: > > > > > It is possible to stack bridges on top of each other. Consider the > > > following which makes use

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-06 Thread Vladimir Oltean
Hi Andrew, On Fri, May 06, 2022 at 12:59:04AM +0200, Andrew Lunn wrote: > It is possible to stack bridges on top of each other. Consider the > following which makes use of an Ethernet switch: > >br1 > /\ > / \ >/\ > br0.11wlan0 >| >br0 > / | \

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-05 Thread Andrew Lunn
On Thu, May 05, 2022 at 04:07:20PM -0700, Stephen Hemminger wrote: > On Fri, 6 May 2022 00:59:04 +0200 > Andrew Lunn wrote: > > > It is possible to stack bridges on top of each other. Consider the > > following which makes use of an Ethernet switch: > > > >br1 > > /\ > > /

Re: [Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-05 Thread Stephen Hemminger
On Fri, 6 May 2022 00:59:04 +0200 Andrew Lunn wrote: > It is possible to stack bridges on top of each other. Consider the > following which makes use of an Ethernet switch: > >br1 > /\ > / \ >/\ > br0.11wlan0 >| >br0 > / | \ > p1 p2 p3 >

[Bridge] [PATCH RFC] net: bridge: Clear offload_fwd_mark when passing frame up bridge interface.

2022-05-05 Thread Andrew Lunn
It is possible to stack bridges on top of each other. Consider the following which makes use of an Ethernet switch: br1 /\ / \ /\ br0.11wlan0 | br0 / | \ p1 p2 p3 br0 is offloaded to the switch. Above br0 is a vlan interface, for vlan 11. This v