Re: [PATCH 0/3] bonding: allow L2 receive on slaves

Re: [PATCH 0/3] bonding: allow L2 receive on slaves

[Joe Eykholt]

Hi Jay and Jeff,

I'm new on this alias and the patch set I submitted on 5/4 is my first 
for Linux.

I'm not sure I'm doing this right, but I have seen no comments at all 
about the
changes.  Would you make some suggestions as to how I should proceed? 

I'm willing to rewrite the patch as necessary to get the problem solved. 
If there's an issue on the basic idea, please let me know what it is.

I saw another recent patch that would allow LLDP to be delivered
on the bond even if it arrived on an inactive slave.  If it would
be more acceptable, we could add FCoE and FIP (being discussed in T11)
as two other exceptions.  This would be low impact as well, but not
as nice for the protocols, IMHO.   For example, if an L2 protocol had
a packet_type using a slave before the bond was created, it would
be cut off from any traffic.

Again, any suggestions would be appreciated. 
I know everyone is busy, so thanks for your time.

    Cheers,
    Joe Eykholt

[PATCH 0/3] bonding: allow L2 receive on slaves

[Joe Eykholt]

This series adds the ability for L2 protocols to specificly receive
on enslaved devices if the packet_type.dev is non-NULL and specifies
the slave.

This change was first described in my post to this alias on March 11.
The patch is slightly different for clarity, but has the same effect.

This is for when active/backup mode is used to bond IP, but
it is still appropriate to handle some L2 protocols (e.g.,
LLDP and FCoE) on the backup (inactive) links.

The existing Linux bonding hook drops (almost) all traffic
being received on the inactive slave interface except for
ARP replies used by bonding itself to test connectivity.

Once we are past the bonding hook, netif_receive_skb()
delivers the packet to all packet_type structures
that match the following criteria:
 1) The type field matches either ETH_P_ALL
    or the received packet's type AND
 2) the dev field is NULL or matches the (master)
    interface dev pointer.

The packet_type.dev field is usually NULL.
Almost all protocols in the kernel initialize the dev
field to NULL and don't touch it.  The only exceptions
are the bonding code itself and AF_PACKET during the bind
operation.

My proposal is to tweak the semantics so that when the
packet_type dev field is non-NULL and matches
the slave device, we deliver the frame to the packet_type
function even in the case where the bonding driver would've
dropped it.

This provides for any L2 protocol and user-level program
using AF_PACKET bound to the individual slave interface.
If AF_PACKET is not bound, it'll receive on all interfaces
still except passive slaves, and will receive from active
slaves as if the frame arrived on the master (the current
behavior).

It's important to note that this is a potential change
for user programs that bind to slave devices, since they
wouldn't have received traffic while the slave was bound in
the past.  I'm not sure how many such programs there might
be so I'm unsure how concerned to be about this.
This however is how I think it should work.

We add a pointer 'null_or_orig' which is NULL in most cases,
but points to the original device in the inactive slave test.
In deciding whether to deliver the packet on a particular
packet_type, now instead of !ptype->dev, we test 
ptype->dev == null_or_orig.

There are related issues with MAC addresses, but I think
there are good solutions to them.

---

Joe Eykholt (3):
      bonding: Allow receive on active slaves.
      bonding:  Allow certain receives on inactive slave.
      bonding: Uninline skb_bond().


 net/core/dev.c |   35 +++++++++++++----------------------
 1 files changed, 13 insertions(+), 22 deletions(-)

-- 
Joe Eykholt <jre@nuovasystems.com>