Re: Scalable Event Channel ABI design (draft A)

[David Vrabel <david.vrabel@citrix.com>]

On 06/02/13 13:53, Keir Fraser wrote:
> On 06/02/2013 11:32, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> 
>>> 4. Get the 3-level ABI to a mergable state. In parallel develop a
>>> prototype of the FIFO-based ABI.  When the prototype is ready or the 4.3
>>> freeze is here, evaluate it and make a decision then.
>>
>> Just to clarify, the difference between #1 and #4 is that in #4 we hold
>> off on the merge, to delay committing to a specific course of action
>> until later?
>>
>> That seems at first blush to be a pretty safe option.  But I think it's
>> worth pointing out that in practice the end result is likely to be that
>> we just go with #1 eventually anyway: if the FIFO ABI can't be finished
>> in 4 months giving it all our effort, can we really expect it to be
>> finished in any less time while polishing up the 3-level ABI?
>>
>> I was going to say, "There's no particular reason to merge the 3-level
>> ABI sooner rather than later", but of course there is: it allows
>> considerably longer and wider testing.
>>
>> No conclusion here, just adding to the mix of things to consider. :-)
> 
> How many man-weeks do we think David's design would take to get to draft
> implementation? I mean honestly I would have thought that a straight
> two-week run at it would be a reasonable estimate -- the places it plugs in
> in hypervisor and guest kernel are pretty clean and well defined.

Your estimate wasn't far off.  After 6 days I now have my first
prototype implementation sending and receiving its first events.

There needs to be some more work on the Xen side to add an explicit hook
for binding new event channels to VCPU0 (so we can hook them up to the
right queue) and the Linux side is limited to 1024 events as Linux isn't
expanding the event array yet.

And it needs more testing of course.

Should be able to post a patch series of the prototype of both the Xen
and Linux sides within a week or so.

David