From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Ferriter, Cian" <cian.ferriter@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Kovacevic, Marko" <marko.kovacevic@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 19.08 v2] net/pcap: enable infinitely rxing a pcap file
Date: Wed, 12 Jun 2019 15:10:25 +0100 [thread overview]
Message-ID: <7ac9657f-e67b-ffc0-1aa3-91693f497aeb@intel.com> (raw)
In-Reply-To: <579B86492DFB364BBA627A48FB30C90E75D518F7@IRSMSX102.ger.corp.intel.com>
On 6/5/2019 1:46 PM, Ferriter, Cian wrote:
> Adding in my changelog at the top of this, since I forgot to add it in the original mail:
>
> v2:
> * Rework the method of filling the ring to infinitely rx from
> * Avoids potential huge allocation of mbufs
> * Removes double allocation of mbufs used during queue setup
> * rename count_packets_in_pcaps to count_packets_in_pcap
> * initialize pcap_pkt_count in count_packets_in_pcap
> * use RTE_PMD_REGISTER_PARAM_STRING <0|1> rather than <int>
> * replace calls to rte_panic with proper error returning
> * count rx and tx stat bytes in pcap_rx_infinite and tx_drop
> * make internals->infinite_rx = infinite_rx assignment unconditional
> * add cleanup for infinite_rx in eth_dev_close and pmd_pcap_remove
> * add cleanup when multi seg mbufs are found
> * add some clarifications to the documentation update
>
>> -----Original Message-----
>> From: Ferriter, Cian
>> Sent: 05 June 2019 12:56
>> To: Richardson, Bruce <bruce.richardson@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Mcnamara, John <john.mcnamara@intel.com>;
>> Kovacevic, Marko <marko.kovacevic@intel.com>
>> Cc: dev@dpdk.org; Ferriter, Cian <cian.ferriter@intel.com>
>> Subject: [PATCH 19.08 v2] net/pcap: enable infinitely rxing a pcap file
>>
>> It can be useful to use pcap files for some rudimental performance testing.
>> This patch enables this functionality in the pcap driver.
>>
>> At a high level, this works by creaing a ring of sufficient size to store the
>> packets in the pcap file passed to the application. When the rx function for
>> this mode is called, packets are dequeued from the ring for use by the
>> application and also enqueued back on to the ring to be "received" again.
>>
>> A tx_drop mode is also added since transmitting to a tx_pcap file isn't
>> desirable at a high traffic rate.
>>
>> Jumbo frames are not supported in this mode. When filling the ring at rx
>> queue setup time, the presence of multi segment mbufs is checked for.
>> The PMD will exit on detection of these multi segment mbufs.
>>
>> Signed-off-by: Cian Ferriter <cian.ferriter@intel.com>
>> ---
>> doc/guides/nics/pcap_ring.rst | 19 +++
>> drivers/net/pcap/rte_eth_pcap.c | 268
>> ++++++++++++++++++++++++++++++--
>> 2 files changed, 277 insertions(+), 10 deletions(-)
>>
>> diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
>> index c1ef9196b..b272e6fe3 100644
>> --- a/doc/guides/nics/pcap_ring.rst
>> +++ b/doc/guides/nics/pcap_ring.rst
>> @@ -106,6 +106,25 @@ Runtime Config Options
>>
>> --vdev 'net_pcap0,iface=eth0,phy_mac=1'
>>
>> +- Use the RX PCAP file to infinitely receive packets
>> +
>> + In case ``rx_pcap=`` configuration is set, user may want to use the
>> + selected PCAP file for rudimental performance testing. This can be done
>> with a ``devarg`` ``infinite_rx``, for example::
>> +
>> + --vdev 'net_pcap0,rx_pcap=file_rx.pcap,infinite_rx=1,tx_drop=1'
Can be good to highlight that this flag is not per queue, but should be provided
once (explictly once since code checks it) per Rx.
>> +
>> + When this mode is used, it is recommended to use the ``tx_drop``
>> ``devarg``.
>> +
>> + This option is device wide, so all queues on a device will either have this
>> enabled or disabled.
>> +
>> +- Drop all packets on transmit
>> +
>> + The user may want to drop all packets on tx for a device. This can be done
>> with the ``tx_drop`` ``devarg``, for example::
>> +
>> + --vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_drop=1'
>> +
>> + One tx drop queue is created for each rxq on that device.
Can we drop the ``tx_drop`` completely?
What happens when no 'tx_pcap' or 'tx_iface' provided at all, to imply the tx_drop?
<...>
>> @@ -1105,7 +1290,8 @@ static int
>> eth_from_pcaps(struct rte_vdev_device *vdev,
>> struct pmd_devargs *rx_queues, const unsigned int
>> nb_rx_queues,
>> struct pmd_devargs *tx_queues, const unsigned int
>> nb_tx_queues,
>> - int single_iface, unsigned int using_dumpers)
>> + int single_iface, unsigned int using_dumpers,
>> + unsigned int infinite_rx, unsigned int tx_drop)
The argument list is keep increasing. What happens is 'pmd_pcap_probe()'
processes the user input (devargs) and passes the processed output to this
function to create ethdev.
What do you think gathering all processed output to a struct and pass it the
this function, in a patch before this patch? Like:
struct pmd_devargs_all {
struct pmd_devargs pcaps;
struct pmd_devargs dumpers;
int single_iface;
unsigned intis_tx_pcap;
};
And add 'unsigned int infinite_rx;' into that struct in this patch.
<...>
>> @@ -1148,6 +1342,7 @@ pmd_pcap_probe(struct rte_vdev_device *dev) {
>> const char *name;
>> unsigned int is_rx_pcap = 0, is_tx_pcap = 0;
>> + unsigned int infinite_rx = 0, infinite_rx_arg_cnt = 0, tx_drop = 0;
Is initial value required for 'infinite_rx_arg_cnt '?
>> struct rte_kvargs *kvlist;
>> struct pmd_devargs pcaps = {0};
>> struct pmd_devargs dumpers = {0};
>> @@ -1216,7 +1411,25 @@ pmd_pcap_probe(struct rte_vdev_device *dev)
>> is_rx_pcap = rte_kvargs_count(kvlist, ETH_PCAP_RX_PCAP_ARG) ? 1
>> : 0;
>> pcaps.num_of_queue = 0;
>>
>> + infinite_rx_arg_cnt = rte_kvargs_count(kvlist,
>> + ETH_PCAP_INFINITE_RX_ARG);
Can move this under 'is_rx_pcap', since this value only make sense when Rx is pcap.
>> +
>> if (is_rx_pcap) {
>> + /*
>> + * We check whether we want to infinitely rx the pcap file.
>> + */
>> + if (infinite_rx_arg_cnt == 1) {
>> + ret = rte_kvargs_process(kvlist,
>> + ETH_PCAP_INFINITE_RX_ARG,
>> + &get_infinite_rx_arg, &infinite_rx);
>> + if (ret < 0)
>> + goto free_kvlist;
>> + } else if (infinite_rx_arg_cnt >= 1) {
I guess it should be ">" instead of ">="
<...>
>> @@ -1285,8 +1512,12 @@ pmd_pcap_probe(struct rte_vdev_device *dev)
>> goto free_kvlist;
>> }
>>
>> + PMD_LOG(INFO, "Configure pmd_pcap: infinite_rx is %s",
>> + infinite_rx ? "enabled" : "disabled");
What do you think printing the message when feature is requested? Instead of
printing each time that it is disabled, which is default behaviour.
<...>
>> @@ -1318,6 +1550,20 @@ pmd_pcap_remove(struct rte_vdev_device *dev)
>> eth_dev->data->mac_addrs = NULL;
>> }
>>
>> + /* Device wide flag, but cleanup must be performed per queue. */
>> + if (internals->infinite_rx) {
>> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>> + struct pcap_rx_queue *pcap_q = &internals-
>>> rx_queue[i];
>> + struct rte_mbuf *pcap_buf;
>> +
>> + while (!rte_ring_dequeue(pcap_q->pkts,
>> + (void **)&pcap_buf))
>> + rte_pktmbuf_free(pcap_buf);
>> +
>> + rte_ring_free(pcap_q->pkts);
>> + }
>> + }
Can it possible to call 'eth_dev_close()' which seems dublicating the above code?
next prev parent reply other threads:[~2019-06-12 14:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 11:56 Cian Ferriter
2019-06-05 12:46 ` Ferriter, Cian
2019-06-12 14:10 ` Ferruh Yigit [this message]
2019-06-14 14:48 ` Ferriter, Cian
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=7ac9657f-e67b-ffc0-1aa3-91693f497aeb@intel.com \
--to=ferruh.yigit@intel.com \
--cc=bruce.richardson@intel.com \
--cc=cian.ferriter@intel.com \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=marko.kovacevic@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).