Re: [Xen-devel] [PATCH 2 of 4 RFC] blktap3/sring: extract requests from the ring, grouping of VBDs

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-03-14 at 17:24 +0000, Thanos Makatos wrote:
> > Also, there is another piece of functionality introduced for which I
> > have some
> > questions: two or more VBDs served by the same tapdisk process can be
> > grouped into a "context". This context carries the handle to the event
> > channel driver used to bind to the guest domain's port in order to
> > receive/send notifications for the shared ring. I don't see any merit
> > by this grouping and I think it should be removed, is there something I
> > am overseeing?
> 
> Actually, I think I just realized what's the purpose of this grouping:
> reduce the number of event channels used for sring notifications,
> right? Correct me if I'm wrong but is there some ongoing work on
> increasing the number of event channels, rendering this optimisation
> useless?

I would expect that you still need an event channel per vbd (since event
channels are point to point), but perhaps this grouping allows you to
save on the number of open file descriptors for /dev/xen/evtchn? (NB:
I've not looked at the code at all).

In general I would say that for both fds and evtchns regardless of the
current limits it is better to try and minimise the number required so
long as the overhead/complexity of doing so is not too big.

Even if you don't hit any actual hard limits I would expect there to be
some soft limits relating to scalability to consider e.g. limitations of
select()/poll() etc as well as the overheads inside the kernel of
maintaining large numbers of open file descriptors etc.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel