[dpdk-dev] [PATCH v4] drivers/net:new PMD using tun/tap host interface

Wiles, Keith keith.wiles at intel.com
Tue Oct 11 22:56:28 CEST 2016


Regards,
Keith

> 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.

> 
> Best Regards,
> Michał Mirosław



More information about the dev mailing list