netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, yotamg@mellanox.com, idosch@mellanox.com,
	mlxsw@mellanox.com, nikolay@cumulusnetworks.com, andrew@lunn.ch,
	dsa@cumulusnetworks.com, edumazet@google.com, willemb@google.com,
	johannes.berg@intel.com, dcaratti@redhat.com, pabeni@redhat.com,
	daniel@iogearbox.net, f.fainelli@gmail.com, fw@strlen.de,
	gfree.wind@vip.163.com
Subject: [patch net-next v2 1/7] skbuff: Add the offload_mr_fwd_mark field
Date: Tue,  3 Oct 2017 09:58:06 +0200	[thread overview]
Message-ID: <20171003075812.1540-2-jiri@resnulli.us> (raw)
In-Reply-To: <20171003075812.1540-1-jiri@resnulli.us>

From: Yotam Gigi <yotamg@mellanox.com>

Similarly to the offload_fwd_mark field, the offload_mr_fwd_mark field is
used to allow partial offloading of MFC multicast routes.

Switchdev drivers can offload MFC multicast routes to the hardware by
registering to the FIB notification chain. When one of the route output
interfaces is not offload-able, i.e. has different parent ID, the route
cannot be fully offloaded by the hardware. Examples to non-offload-able
devices are a management NIC, dummy device, pimreg device, etc.

Similar problem exists in the bridge module, as one bridge can hold
interfaces with different parent IDs. At the bridge, the problem is solved
by the offload_fwd_mark skb field.

Currently, when a route cannot go through full offload, the only solution
for a switchdev driver is not to offload it at all and let the packet go
through slow path.

Using the offload_mr_fwd_mark field, a driver can indicate that a packet
was already forwarded by hardware to all the devices with the same parent
ID as the input device. Further patches in this patch-set are going to
enhance ipmr to skip multicast forwarding to devices with the same parent
ID if a packets is marked with that field.

The reason why the already existing "offload_fwd_mark" bit cannot be used
is that a switchdev driver would want to make the distinction between a
packet that has already gone through L2 forwarding but did not go through
multicast forwarding, and a packet that has already gone through both L2
and multicast forwarding.

For example: when a packet is ingressing from a switchport enslaved to a
bridge, which is configured with multicast forwarding, the following
scenarios are possible:
 - The packet can be trapped to the CPU due to exception while multicast
   forwarding (for example, MTU error). In that case, it had already gone
   through L2 forwarding in the hardware, thus A switchdev driver would
   want to set the skb->offload_fwd_mark and not the
   skb->offload_mr_fwd_mark.
 - The packet can also be trapped due to a pimreg/dummy device used as one
   of the output interfaces. In that case, it can go through both L2 and
   (partial) multicast forwarding inside the hardware, thus a switchdev
   driver would want to set both the skb->offload_fwd_mark and
   skb->offload_mr_fwd_mark.

Signed-off-by: Yotam Gigi <yotamg@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellaox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
 include/linux/skbuff.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 19e64bf..ada8214 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -772,6 +772,7 @@ struct sk_buff {
 	__u8			remcsum_offload:1;
 #ifdef CONFIG_NET_SWITCHDEV
 	__u8			offload_fwd_mark:1;
+	__u8			offload_mr_fwd_mark:1;
 #endif
 #ifdef CONFIG_NET_CLS_ACT
 	__u8			tc_skip_classify:1;
-- 
2.9.5

  reply	other threads:[~2017-10-03  7:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03  7:58 [patch net-next v2 0/7] mlxsw: Add support for partial multicast route offload Jiri Pirko
2017-10-03  7:58 ` Jiri Pirko [this message]
2017-10-03  7:58 ` [patch net-next v2 2/7] ipv4: ipmr: Add the parent ID field to VIF struct Jiri Pirko
2017-10-03 10:25   ` Nikolay Aleksandrov
2017-10-03  7:58 ` [patch net-next v2 3/7] ipv4: ipmr: Don't forward packets already forwarded by hardware Jiri Pirko
2017-10-03 10:26   ` Nikolay Aleksandrov
2017-10-03  7:58 ` [patch net-next v2 4/7] mlxsw: acl: Introduce ACL trap and forward action Jiri Pirko
2017-10-03  7:58 ` [patch net-next v2 5/7] mlxsw: spectrum: Add trap for multicast trap-and-forward routes Jiri Pirko
2017-10-03  7:58 ` [patch net-next v2 6/7] mlxsw: spectrum: mr_tcam: Add trap-and-forward multicast route Jiri Pirko
2017-10-03  7:58 ` [patch net-next v2 7/7] mlxsw: spectrum: mr: Support trap-and-forward routes Jiri Pirko
2017-10-03 17:07 ` [patch net-next v2 0/7] mlxsw: Add support for partial multicast route offload David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003075812.1540-2-jiri@resnulli.us \
    --to=jiri@resnulli.us \
    --cc=andrew@lunn.ch \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dcaratti@redhat.com \
    --cc=dsa@cumulusnetworks.com \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=fw@strlen.de \
    --cc=gfree.wind@vip.163.com \
    --cc=idosch@mellanox.com \
    --cc=johannes.berg@intel.com \
    --cc=mlxsw@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    --cc=yotamg@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).