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

[Ido Goshen <Ido@cgstowernetworks.com>]

I think we are starting to mix two things
One is how to configure pcap eth dev with multiple queues and I totally agree it would have been nicer to just say something like "max_tx_queues =N" instead of needing to write "tx_iface" N times, but as it was already supported in that way (for any reason?) I wasn't trying to enhance or change it.
The other issue is pcap direction API, which I was trying to expose to users of dpdk pcap device.
Refer to https://www.tcpdump.org/manpages/pcap_setdirection.3pcap.txt or man tcpdump for -P/--direction in|out|inout option, 
Actually I think a more realistic emulation of a physical device (non-virtual) would be to capture only the incoming direction (set PCAP_D_IN), again the existing behavior is very useful too and I didn't try to change or eliminate it but just add additional stream type option

-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com> 
Sent: Thursday, June 14, 2018 9:09 PM
To: Ido Goshen <Ido@cgstowernetworks.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] net/pcap: rx_iface_in stream type support

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@intel.com>
> Sent: Wednesday, June 13, 2018 1:57 PM
> To: Ido Goshen <Ido@cgstowernetworks.com>
> Cc: dev@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
>