Thread (71 messages) 71 messages, 10 authors, 2012-09-04

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

flat view

From: Or Gerlitz <hidden>
Date: 2012-08-04 21:23:21

On Sat, Aug 4, 2012 at 2:36 AM, David Miller [off-list ref] wrote:
From: Ali Ayoub <redacted>
Date: Fri, 03 Aug 2012 15:39:36 -0700
quoted
Users would like to use sockets API from the VM without re-writing their
applications on top of IB verbs, this driver meant to allow such a user
to do so.
That's what IPoIB was for, the application writers who don't want to have
to be knowledgable about IB verbs.

You're messing with the link layer here, and that's what is upsetting me.

It's a complete cop-out to changing the VM tools and emulators properly to
handle a new link layer.

The applications writers already have a way to use IB whilst using
something familiar, like IPv4, via IPoIB.  You're doing something
completely different here, and it stinks.

Dave,

Just quick recap of things to make sure we're in sync on the facts
here and (me) trying to better follow your arguments:

Bringing IB to app usage is done through the IB verbs / RDMA CM, which
is supported
for quite a long while for native mode and BTW as for SRIOV, there's a
now running patch set @ linux-rdma submitted to Roland
http://marc.info/?l=linux-rdma&m=134398354428293&w=2

IPoIB is meant to allow IP apps to use IB, defined by IETF spec (RFC 4391/4392)

The idea in eIPoIB was to allow IP apps running on VMs under a
Para-Virtual set of mind, e.g when the Linux PV networking stack comes
into play, to use that stack w.o modifying it.

When looking on that, we thought so far so good, and went in the way
posted here. If reusing your last sentence... this driver provides a
way for apps to use the PV stack AND IB whilst using something
familiar, like IPv4.


I'd like to better understand your "messing with the link layer here,
and that's what is upsetting" claim --- since the service here is IP,
and this service has well defined mechanisms, eIPoIB is basically a
shim layer that allows to provide this service for VMs that interacts
with the emulators, drivers and tools used in Linux and the related
guest OS PV drivers (virtio and friends). For example, that messing
mostly goes down to translating ARP requests/replies from being
carried in Ethernet frame to be carried in IPoIB packet, is that
really too hacky? why and what?

Or.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help