On 05/20/2015 04:04 PM, Andy Gospodarek wrote:
Well I can now delete most of my initial response. :)
Overall I would say this is really cool functionality. Even if you do
not want it merged, I think it is great that you shared it with the
community this way. I got a chance to look at is a bit this morning and
I agree additional explanation of the algorithm you are using would
probably be nice for those checking this out for the first time.
Thanks :) I explained the algorithm in my last email to the list, so I
won't repeat it here.
I also think if you would be able to leverage the exiting bonding infra
for using skb->queue_mapping you could probably add the same
functionality (though it might be higher in the stack), but I totally
understand if you want to just keep using what you are using as-is.
I didn't know about the queue_mapping thing. Thanks for the pointer.
One thing I considered doing that I didn't ultimately do was try to
implement this as a TUN device. Userspace coding is always easier and,
in retrospect, finding some way to manually parse IP and TCP packet
headers would likely have been trying to debug kernel memory corruption
bugs. But another downside would have been that I'm pretty sure all the
slaves would have had to have been set to promiscuous mode to make it work.
--Patrick Simmons
--
If I'm not here, I've gone out to find myself. If I get back before I
return, please keep me here.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
