diff mbox

[net-next,5/5] switchdev: update documentation for offload_fwd_mark

Message ID 1436397403-62412-6-git-send-email-sfeldma@gmail.com
State Changes Requested, archived
Delegated to: David Miller
Headers show

Commit Message

Scott Feldman July 8, 2015, 11:16 p.m. UTC
From: Scott Feldman <sfeldma@gmail.com>

Signed-off-by: Scott Feldman <sfeldma@gmail.com>
---
 Documentation/networking/switchdev.txt |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

Comments

Simon Horman July 9, 2015, 4:27 a.m. UTC | #1
On Wed, Jul 08, 2015 at 04:16:43PM -0700, sfeldma@gmail.com wrote:
> From: Scott Feldman <sfeldma@gmail.com>
> 
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> ---
>  Documentation/networking/switchdev.txt |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
> index c5d7ade..b864e47 100644
> --- a/Documentation/networking/switchdev.txt
> +++ b/Documentation/networking/switchdev.txt
> @@ -279,8 +279,18 @@ and unknown unicast packets to all ports in domain, if allowed by port's
>  current STP state.  The switch driver, knowing which ports are within which
>  vlan L2 domain, can program the switch device for flooding.  The packet should
>  also be sent to the port netdev for processing by the bridge driver.  The
> -bridge should not reflood the packet to the same ports the device flooded.
> -XXX: the mechanism to avoid duplicate flood packets is being discuseed.
> +bridge should not reflood the packet to the same ports the device flooded,
> +otherwise there will be duplicate packets on the wire.
> +
> +To avoid duplicate packets, the device/driver can mark a packet as already

I wonder if  'should' or 'may' would be clearer than 'can'.

> +forwarded using skb->offload_fwd_mark.  The same mark is set on the device
> +ports in the domain using dev->offload_fwd_mark.  If the skb->offload_fwd_mark
> +is non-zero and matches the forwarding egress port's dev->skb_mark, the kernel
> +will drop the skb right before transmit on the egress port, with the
> +understanding that the device already forwarded the packet on same egress port.
> +The driver can use switchdev_port_fwd_mark_set() to set a globally unique mark
> +for port's dev->offload_fwd_mark, based on the port's parent ID (switch ID) and
> +a group ifindex.
>  
>  It is possible for the switch device to not handle flooding and push the
>  packets up to the bridge driver for flooding.  This is not ideal as the number
> -- 
> 1.7.10.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Scott Feldman July 9, 2015, 5:57 a.m. UTC | #2
On Wed, Jul 8, 2015 at 9:27 PM, Simon Horman <simon.horman@netronome.com> wrote:
> On Wed, Jul 08, 2015 at 04:16:43PM -0700, sfeldma@gmail.com wrote:
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>> ---
>>  Documentation/networking/switchdev.txt |   14 ++++++++++++--
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
>> index c5d7ade..b864e47 100644
>> --- a/Documentation/networking/switchdev.txt
>> +++ b/Documentation/networking/switchdev.txt
>> @@ -279,8 +279,18 @@ and unknown unicast packets to all ports in domain, if allowed by port's
>>  current STP state.  The switch driver, knowing which ports are within which
>>  vlan L2 domain, can program the switch device for flooding.  The packet should
>>  also be sent to the port netdev for processing by the bridge driver.  The
>> -bridge should not reflood the packet to the same ports the device flooded.
>> -XXX: the mechanism to avoid duplicate flood packets is being discuseed.
>> +bridge should not reflood the packet to the same ports the device flooded,
>> +otherwise there will be duplicate packets on the wire.
>> +
>> +To avoid duplicate packets, the device/driver can mark a packet as already
>
> I wonder if  'should' or 'may' would be clearer than 'can'.

'should' sounds better; v2.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt
index c5d7ade..b864e47 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -279,8 +279,18 @@  and unknown unicast packets to all ports in domain, if allowed by port's
 current STP state.  The switch driver, knowing which ports are within which
 vlan L2 domain, can program the switch device for flooding.  The packet should
 also be sent to the port netdev for processing by the bridge driver.  The
-bridge should not reflood the packet to the same ports the device flooded.
-XXX: the mechanism to avoid duplicate flood packets is being discuseed.
+bridge should not reflood the packet to the same ports the device flooded,
+otherwise there will be duplicate packets on the wire.
+
+To avoid duplicate packets, the device/driver can mark a packet as already
+forwarded using skb->offload_fwd_mark.  The same mark is set on the device
+ports in the domain using dev->offload_fwd_mark.  If the skb->offload_fwd_mark
+is non-zero and matches the forwarding egress port's dev->skb_mark, the kernel
+will drop the skb right before transmit on the egress port, with the
+understanding that the device already forwarded the packet on same egress port.
+The driver can use switchdev_port_fwd_mark_set() to set a globally unique mark
+for port's dev->offload_fwd_mark, based on the port's parent ID (switch ID) and
+a group ifindex.
 
 It is possible for the switch device to not handle flooding and push the
 packets up to the bridge driver for flooding.  This is not ideal as the number