Re: [PATCH/RFC 7/9] Virtual network guest device driver

Anthony Liguori
2007-05-16T18:47:04Z

Eric Van Hensbergen wrote:
> On 5/16/07, Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> What do you think about a socket interface? I'm not sure how discovery
>> would work yet, but there are a few PV socket implementations for Xen at
>> the moment.
>>
>
> From a functional standpoint I don't have a huge problem with it,
> particularly if its more of a pure socket and not something that tries
> to look like a TCP/IP endpoint -- I would prefer something closer to
> netlink. Sockets would allow the exisitng 9p stuff to pretty much
> work as-is.

So you would prefer assigning out types instead of using an identifier
string in the sockaddr?

> However, all that being said, I noticed some pretty big differences
> between sockets and shared memory in terms of overhead under Linux.
>
> If you take a look at the RPC latency graph in:
> http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
>
> You'll see that a local socket implementation has about an order of
> magnitude worse latency than a PROSE/Libra inter-partition shared
> memory channel.

You seem to suggest that the low latency is due to a very greedy (CPU
hungry) polling algorithm. A poll vs. interrupt model would seem to me
to be orthogonal to using sockets as an interface.

> Furthermore it will really limit our ability to trim
> the fat of unnecessary copies in order to have competitive
> performance. But perhaps there's magic you can do to eliminate that.

sockets do add copies. My initial thinking is that one can work around
this by passing guest PFNs (or grant references in Xen). I'm also happy
to start out focusing on "low-speed" devices.

> Of course, you could always layer a socket interface for userspace
> simplicity on top of a more performance-optimized underlying transport
> that could be used directly by kernel-modules.

Right.

Regards,

Anthony Liguori

> -eric