2016-10-11 22:56 GMT+02:00 Wiles, Keith <keith.wiles at intel.com>:
>> On Oct 11, 2016, at 6:30 AM, Micha? Miros?aw <mirqus at gmail.com> wrote:
>>
>> 2016-10-04 16:45 GMT+02:00, Keith Wiles <keith.wiles at intel.com>:
>>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces
>>> on the local host. The PMD allows for DPDK and the host to
>>> communicate using a raw device interface on the host and in
>>> the DPDK application. The device created is a Tap device with
>>> a L2 packet header.
>> [...]
>>> +static uint16_t
>>> +pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>>> +{
>>> + int len, n;
>>> + struct rte_mbuf *mbuf;
>>> + struct rx_queue *rxq = queue;
>>> + struct pollfd pfd;
>>> + uint16_t num_rx;
>>> + unsigned long num_rx_bytes = 0;
>>> +
>>> + pfd.events = POLLIN;
>>> + pfd.fd = rxq->fd;
>>> + for (num_rx = 0; num_rx < nb_pkts; ) {
>>> + n = poll(&pfd, 1, 0);
>>> +
>>> + if (n <= 0)
>>> + break;
>>> +
>>
>> Considering that syscalls are rather expensive, it would be cheaper to
>> allocate an mbuf here and free it when read() returns -1 instead of
>> calling poll() to check whether a packet is waiting. This way you
>> save a syscall per packet and replace one syscall with one mbuf free
>> per poll.
>
> I made this change, but saw no performance difference in the two methods.
> Removing poll seems reasonable as it is simpler. TAP is already so slow is
> why the performance did not change is my guess. Anyone wanting to use TAP as
> a high performance interface is going to be surprised. I believe the best use
> case for the TAP interface is for control or exception path.
Agreed, TAP does not look like designed for performance as a first goal.
You could do the same simplification for TX path, BTW.
Best Regards,
Micha? Miros?aw
