Re: [Xen-devel] [PATCH v10 4/5] remus: implement remus network buffering for nic devices

[Hongyang Yang <yanghy@xxxxxxxxxxxxxx>]

On 06/06/2014 01:56 AM, Shriram Rajagopalan wrote:
> On Jun 5, 2014 11:14 PM, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx
> <mailto:Ian.Jackson@xxxxxxxxxxxxx>> wrote:
>  >
>  > Ian Jackson writes ("Re: [PATCH v10 4/5] remus: implement remus network
> buffering for nic devices"):
>  > > Shriram Rajagopalan writes ("Re: [PATCH v10 4/5] remus: implement remus
> network buffering for nic devices"):
>  > > ...
>  > > > The async execution for each netlink call is an overkill.  These
>  > > > rtnl calls complete in a matter of few microseconds utmost. On the
>  > > > other hand, this code structure, fork/execs a new process for every
>  > > > checkpoint just to execute a single library call (netbuf_epoch_op),
>  > > > which in turn issues just a syscall.
>  > >
>  > > I haven't read the code to check whether this criticism is accurate,
>  > > but if it is I think it would be justified.
>  > >
>  > > There is no need to use the async machinery for fast system calls.
>  >
>  > Having read Shriram's other mail, I feel the need to emphasise the
>  > qualification "fast".
>  >
>  > "Fast" means "cannot ever, even in error conditions, take a
>  > significant amount of time".  In particular anything that waits for
>  > incoming network traffic is not "fast".
>  >
>  > But AFAICT by looking at the code we are talking only about these
>  > calls:
>  >   rtnl_qdisc_plug_buffer
>  >   rtnl_qdisc_plug_release_one
>  >   rtnl_qdisc_add
>  > Surely these always complete immediately.
>  >
>
> Yes. They boil down to a netlink syscall that simply communicates with qdisc
> manipulation routines in the kernel. They have nothing to do with waiting for
> network traffic.
The question is whether these checkpoints need to be async ops. for netbuffer 
and drbd calls, may not necessary since they are quick. but we do not sure other 
remus device type's ops(which we do not implemented currently) are quick 
enough.So for the interface, make it an async op is a good choice for now?
> Shriram
--
Thanks,
Yang.

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