Gregory Haskins wrote:
quoted text
>> If you have a request-response workload with the wire idle and latency
>> critical, then there's no problem having an exit per packet because
>> (a) there aren't that many packets and (b) the guest isn't doing any
>> batching, so guest overhead will swamp the hypervisor overhead.
>>     
> Right, so the trick is to use an algorithm that adapts here.  Batching
> solves the first case, but not the second.  The bidir napi thing solves
> both, but it does assume you have ample host processing power to run the
> algorithm concurrently.  This may or may not be suitable to all
> applications, I admit.
>   

The alternative is to get a notification from the stack that the packet 
is done processing.  Either an skb destructor in the kernel, or my new 
API that everyone is not rushing out to implement.

quoted text
>>> Right now its way way way worse than 2us.  In fact, at my last reading
>>> this was more like 3060us (3125-65).  So shorten that 3125 to 67 (while
>>> maintaining line-rate) and I will be impressed.  Heck, shorten it to
>>> 80us and I will be impressed.
>>>   
>>>       
>> The 3060us thing is a timer, not cpu time.
>>     
> Agreed, but its still "state of the art" from an observer perspective. 
> The reason "why", though easily explainable, is inconsequential to most
> people.  FWIW, I have seen virtio-net do a much more respectable 350us
> on an older version, so I know there is plenty of room for improvement.
>   

All I want is the notification, and the timer is headed into the nearest 
landfill.


-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html