From: Ido Goshen <Ido@cgstowernetworks.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] net/pcap: rx_iface_in stream type support
Date: Thu, 14 Jun 2018 20:44:56 +0000 [thread overview]
Message-ID: <AM5PR0901MB14273303FC0326693A510A6AD67D0@AM5PR0901MB1427.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <47bb9ab0-eee9-00cc-5e57-3cc79efcd417@intel.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
>
next prev parent reply other threads:[~2018-06-14 20:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 9:39 ido goshen
2018-06-05 13:26 ` Ferruh Yigit
2018-06-05 17:10 ` Ido Goshen
2018-06-13 10:57 ` Ferruh Yigit
2018-06-14 17:14 ` Ido Goshen
2018-06-14 18:09 ` Ferruh Yigit
2018-06-14 20:44 ` Ido Goshen [this message]
2018-06-15 12:53 ` Ferruh Yigit
2018-06-16 9:27 ` Ido Goshen
2018-06-18 8:13 ` Ferruh Yigit
2018-06-18 9:49 ` Ido Goshen
2018-06-20 18:04 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM5PR0901MB14273303FC0326693A510A6AD67D0@AM5PR0901MB1427.eurprd09.prod.outlook.com \
--to=ido@cgstowernetworks.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).