Re: [PATCH v3 0/1] netif: staging grants for I/O requests

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Joao Martins [mailto:joao.m.martins@oracle.com]
> Sent: 18 September 2017 12:36
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Xen-devel <xen-devel@lists.xen.org>; Wei Liu <wei.liu2@citrix.com>;
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Subject: Re: [PATCH v3 0/1] netif: staging grants for I/O requests
> 
> On Mon, Sep 18, 2017 at 09:45:06AM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Joao Martins [mailto:joao.m.martins@oracle.com]
> > > Sent: 13 September 2017 19:11
> > > To: Xen-devel <xen-devel@lists.xen.org>
> > > Cc: Wei Liu <wei.liu2@citrix.com>; Paul Durrant
> <Paul.Durrant@citrix.com>;
> > > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>; Joao Martins
> > > <joao.m.martins@oracle.com>
> > > Subject: [PATCH v3 0/1] netif: staging grants for I/O requests
> > >
> > > Hey,
> > >
> > > This is v3 taking into consideration all comments received from v2
> (changelog
> > > in the first patch). The specification is right after the diffstat.
> > >
> > > Reference implementation also here (on top of net-next):
> > >
> > > https://github.com/jpemartins/linux.git xen-net-stg-gnts-v3
> > >
> > > Although I am satisfied with how things are being done above, I wanted
> > > to request some advise/input on whether there could be a simpler way
> of
> > > achieving the same. Specifically because these control messages
> > > adds up significant code on the frontend to pregrant, and in other cases
> the
> > > control message might be limitative if frontend tries to keep a dinamically
> > > changed buffer pool in different queues. *Maybe* it could be simpler to
> > > adjust
> > > the TX/RX ring ABI in a compatible matter (Disclaimer: I haven't
> implemented
> > > this just yet):
> >
> > But the whole point of pre-granting is to separate the grant/ungrant
> > operations from the rx/tx operations, right?
> 
> /nods
> 
> > So, why would the extra
> > control messages really be an overhead?
> 
> It's not that it's an overhead, but more like the bigger amount of code
> to pregrant once ... and so I was trying to figure out if there was some
> simplification/flexibility that could be made; in the meantime I was
> experimenting a bit and it looks that won't probably make too much
> difference implementation-wise while implying higher complexity on the
> datapath and also weaker semantics.
> 
> With things like AF_PACKET v4 (pre mapping buffers) appearing in linux
> mid term, it will require stronger semantics like those provided by the
> control ring ops rather than these flags I was suggesting below.
> 
> The advantage with the flags though is that add/del mappings would be
> (by design) on the context of the queue rather than in the control
> ring thread handling it. But maybe this can be considered implementation
> specific behaviour too and we could find ways to handle that better if it
> ever becomes a problem e.g. doing the pre{un,}maps on dealloc thread
> context.
> 

Yes, let's not introduce unnecessary complexity at this stage. If optimizations are needed then they can be dealt with later.

Cheers,

  Paul

> Joao
> 

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