On 03/24/2015 11:14 AM, Scott Feldman wrote:

On Tue, Mar 24, 2015 at 10:58 AM, Guenter Roeck [off-list ref] wrote:

quoted

On Tue, Mar 24, 2015 at 10:45:03AM -0700, roopa wrote:

quoted

On 3/24/15, 9:01 AM, Guenter Roeck wrote:

quoted

On Tue, Mar 24, 2015 at 03:29:21PM +0100, Jiri Pirko wrote:

quoted

quoted

diff --git a/drivers/net/ethernet/rocker/rocker.c

b/drivers/net/ethernet/rocker/rocker.c
index aab962c..0f7217f7 100644

--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c

@@ -3931,15 +3931,28 @@ unmap_frag:
        return -EMSGSIZE;

}

+static bool rocker_port_dev_check(struct net_device *dev);
+
static netdev_tx_t rocker_port_xmit(struct sk_buff *skb, struct
net_device *dev)
{
        struct rocker_port *rocker_port = netdev_priv(dev);
        struct rocker *rocker = rocker_port->rocker;
        struct rocker_desc_info *desc_info;
        struct rocker_tlv *frags;
+       struct net_device *in_dev;
        int i;
        int err;

+       if (rocker_port_is_bridged(rocker_port)) {
+               rcu_read_lock();
+               in_dev = dev_get_by_index_rcu(dev_net(dev), skb->skb_iif);

Hmm, you iterate over all ports for every xmit call :/
Would be nicer if skb_iif would be netdev poiter. Not sure it is doable.

It may be easier (and faster) to loop through all rocker ports and try to find
one with the same ifindex. Then the dev_check call would not be necessary.

This is still overhead for every packet on the switches we support. The
number of ports can go close to 128
(40G ports can be broken into 4x10G ports).

Agreed. Given that, and since dev_get_by_index_rcu uses a hash to find the
device pointer, it may actually be (much) faster (and the above "iterate
over all ports" is a bit misleading).

I tested the above approach with DSA and a Marvell switch chip. It works,
but I am a bit concerned about the per-packet overhead, especially
in larger networks. I would prefer if there would be a means to 'catch'
duplicate packets earlier - before they are even created, if that is
possible.

I'm not so concerned about the per-packet overhead.  For multicast, we
have IGMP snooping.  And big switches are going to have rate controls
on CPU bound traffic, so the CPU should be able to handle the
per-packet overhead with ease.

Ok, next question: Are there any legitimate reasons why a packet might be
sent out on the same interface ? Examples might be packets received through
a VPN or other tunnel and forwarded to the local network, or packets forwarded
in L3 (for example if there are multiple L3 networks on the same link).
Would skb_iif be set for such packets ?

Guenter