Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
> Sent: 04 January 2016 11:18
> To: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson
> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control
> ring and toeplitz hashing
> 
> On 04/01/16 11:14, Paul Durrant wrote:
> >>>> You should use the standard ring format and infrastructure.
> >>>
> >>> Is there one for variable message size rings? I didn't find one. I
> >>> don't want to use the fixed size balanced ring macros for control
> >>> messages as fixed size messages really aren't appropriate in this case.
> >>
> >> Perhaps union the request/response message types with a uint8_t
> >> pad[1024] and use this as the request/response type?
> >>
> >
> > The problem is that this places a 1k limit on the message size,
> > which
> > is not there in the scheme I'm proposing. I'd rather not bake that limit
> > in if I don't have to.
> 
> >>>>> + * |                      req[1024]                |
>                                  ^^^^^^^^^
> Surely this limits your size to 1024 bytes?

No, I've already got prototype code that can pass 4k messages. Nothing in the 
protocol says the whole message has to fit in the buffer. In fact I've 
explicitly documented how to handle partial messages.

> 
> Also if you need bigger messages you can grant those areas separately
> and pass a grant ref through the ring, or you can chunk the message to
> fit in several requests/responses.

Why go to that trouble to wedge a square peg into a round hole? What is the 
fundamental problem with what I've proposed that you want to avoid?

  Paul

> 
> David

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