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

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Jun 5, 2014 11:14 PM, "Ian Jackson" <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.

Shriram

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