Re: [PATCH 3/3] net: deliver skbs on inactive slaves to exact matches

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jay Vosburgh
Date: Wednesday, June 2, 2010 - 1:01 pm

David Miller <davem@davemloft.net> wrote:


	I've looked at it, and was initially hoping to combine this with
Andy/Neil's vaguely similar changes, but I don't see a reasonable way to
do that.

	I think the functionality is reasonable, i.e., adding a facility
to implement "direct bind" delivery of packets on inactive bonding
slaves (where direct bind means that the struct packet_type has a
non-NULL dev).

	I have a couple of concerns about the patch itself:


	First, this looks like too much #ifdef soup here.  None of the
bonding-specific code in the packet receive processing path has
historically been #ifdefed out; there are more examples further down in
the patch.

	Second, should the field be named something generic, e.g.,
"deliver_no_wcard" to indicate its function?  "bond_should_drop" doesn't
really describe what the field is used for (which is to specify that the
packet should be delivered only to non-wildcard packet handlers).  With
this change, packets are never dropped outright as the result of what
the bonding "should drop" logic says.

	I'm open to alternatives to using a field in the sk_buff; John's
original submission added a PACKET_DROP (to supplant PACKET_LOCAL,
PACKET_BROADCAST, etc), but that seemed like a loss of information to
me.  I haven't thought of a way to efficiently accomplish John's goal
without putting state into the skb somewhere.

	-J


---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
--
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
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 3/3] net: deliver skbs on inactive slaves to ex ..., Jay Vosburgh, (Wed Jun 2, 1:01 pm)