[dpdk-dev] [PATCH v2] net/pcap: rx_iface_in stream type support

[Ferruh Yigit]

On 6/14/2018 6:14 PM, Ido Goshen wrote:
> I use "rx_iface","tx_iface" (and not just "iface") in order to have multiple TX queues
> I just gave a simplified setting with 1 queue
> My app  does a full mesh between the ports (not fixed pairs like l2fwd) so all the forwarding lcores can tx to the same port simultaneously
> and as DPDK docs say:
> "Multiple logical cores should never share receive or transmit queues for interfaces since this would require global locks and hinder performance."
> For example if I have 3 ports handled by 3 cores it'll be 
> 	myapp -c 7 -n1 --no-huge \
> 	--vdev=eth_pcap0,rx_iface=eth0,tx_iface=eth0,tx_iface=eth0,tx_iface=eth0 \
> 	--vdev=eth_pcap0,rx_iface=eth1,tx_iface=eth1,tx_iface=eth1,tx_iface=eth1 \
> 	--vdev=eth_pcap0,rx_iface=eth2,tx_iface=eth2,tx_iface=eth2,tx_iface=eth2 \
> 	-- -p 7
> Is there another way to achieve multiple queues in pcap vdev?

If you want to use multiple core you need multiple queues, as you said, and
above is the way to create multiple queues for pcap.

Currently "iface" argument only supports single interface in a hardcoded way,
but technically it should be possible to update it to support multiple queue.

So if "iface" arguments works for you, it can be better to add multi queue
support to "iface" instead of introducing a new device argument.

> 
> I do see that using "iface" behaves differently - I'll try to investigate why

pcap_open_live() is called for both arguments, for "rx_iface/tx_iface" pair it
has been called twice one for each. Not sure if pcap library returns same
handler or two different handlers for this case since iface name is same.
For "iface" argument pcap_open_live() called once, so we have single handler for
both Rx & Tx. This may be difference.

> And still even when using "iface" I also see packets that are transmitted out of eth1 (e.g. tcpreplay -i eth1 packets.pcap) 
> and not only packets that are received (e.g. ping from far end to eth0 ip)

This is interesting, I have tried with external packet generator, "iface" was
working as expected for me.

> 
> 
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit at intel.com> 
> Sent: Wednesday, June 13, 2018 1:57 PM
> To: Ido Goshen <Ido at cgstowernetworks.com>
> Cc: dev at dpdk.org
> Subject: Re: [PATCH v2] net/pcap: rx_iface_in stream type support
> 
> On 6/5/2018 6:10 PM, Ido Goshen wrote:
>> The problem is if a dpdk app uses the same iface(s) both as rx_iface and tx_iface then it will receive back the packets it sends.
>> If my app sends a packet to portid=X with rte_eth_tx_burst() then I 
>> wouldn't expect to receive it back by rte_eth_rx_burst() for that same portid=X  (assuming of course there's no external loopback) This is coming from the default nature of pcap that like a sniffer captures both incoming and outgoing direction.
>> The patch provides an option to limit pcap rx_iface to get only incoming traffic which is more like a real (non-pcap) dpdk device.
>>
>> for example:
>> when using existing *rx_iface*
>> 	l2fwd -c 3 -n1 --no-huge --vdev=eth_pcap0,rx_iface=eth1,tx_iface=eth1 
>> --vdev=eth_pcap1,rx_iface=dummy0,tx_iface=dummy0  -- -p 3 -T 1 sending 
>> only 1 single packet into eth1 will end in an infinite loop -
> 
> If you are using same interface for both Rx & Tx, why not using "iface=xxx"
> argument, can you please test with following:
> 
> l2fwd -c 3 -n1 --no-huge --vdev=eth_pcap0,iface=eth1
> --vdev=eth_pcap1,iface=dummy0 -- -p 3 -T 1
> 
> 
> I can't reproduce the issue with above command.
> 
> Thanks,
> ferruh
>