Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality

Or Gerlitz [off-list ref] writes:

On Tue, Sep 4, 2012 at 12:22 AM, Michael S. Tsirkin [off-list ref] wrote:

quoted

On Mon, Sep 03, 2012 at 11:53:56PM +0300, Or Gerlitz wrote:

quoted

quoted

So we are remained with #3 - the ARPs -- thinking on this a little
further, FWIW there --are-- components in the kernel which
mangle/generate ARPs and are exposing netdevice, such as openvswitch, anyway:

quoted

quoted

does it make sense to forward ARPs received into / sent over the
eIPoIB netdevice (e.g using some sort of rule) to some outer entity
such as user-space daemon  for interception and later re-injection into eIPoIB?

quoted

Well if this is all you want to do, you can bind a packet socket to the
interface, and drop them at the nic.  It is harder to do for incoming
ARP requests though.

quoted

I would do something else: send ARPs out to some defined IB address.
This could be local host or queries from some SA property.  Said remote
side could send you the responses in ethernet format so you do not need
to mangle responses at all.  Similarly for incoming ARP requests.

quoted

The rule to do this can also just redirect non IP packets - this is IPoIB after all.

Thanks for the heads up on the possible implementation route, will
look into that.

quoted

quoted

Documentation we will fix,

quoted

And just to stress the point, document the limitations as well.

sure, not that I see concrete limitations for the **user** at this point, but
if there are such, will put them clearly written.

So far you are still playing with a design that is strongly NOT
ethernet.  So calling it eIPoIB will continue to be a LIE.

You are still playing with an implementation that doesn't even dream
of supporting IPv6 which makes it so far from ethernet I can't imagine
anyone taking your code seriously.

All ethernet protocols not working except IPv4 is a huge concrete
limitation.

Any implementation that breaks a naive ARP implementation also breaks
IPv6.  Not to mention everything else that runs over ethernet.

If you are clever you can use the current IPoIB hardware accelleration
but you need to do something different so that you can either encode
or imply the MAC address so you won't have to munge ethernet protocols.

Just for fun you might want to consider what it takes to support 2 VMs
in the same VLAN that share the same IP address (but different MAC
addresses) for failover purposes.

Eric