[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.