From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Ido Goshen <Ido@cgstowernetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] net/pcap: multiple queues fix
Date: Tue, 19 Jun 2018 11:00:23 +0100 [thread overview]
Message-ID: <9cd6a50f-719e-b0b7-f285-bd85fcf7847f@intel.com> (raw)
In-Reply-To: <AM5PR0901MB14278823FCDB64CA82A8AB6AD6700@AM5PR0901MB1427.eurprd09.prod.outlook.com>
On 6/19/2018 10:45 AM, Ido Goshen wrote:
> See Inline prefixed with [ido]
>
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, June 18, 2018 11:25 AM
> To: Ido Goshen <Ido@cgstowernetworks.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH 1/2] net/pcap: multiple queues fix
>
> On 6/16/2018 4:36 PM, ido goshen wrote:
>> Change open_rx/tx_pcap/iface functions to open only a single
>> pcap/dumper and not loop num_of_queue times The num_of_queue loop is
>> already acheived by the caller rte_kvargs_process
>
> You are right, thanks for fixing this, a few comments below.
>
>>
>> Fixes:
>> 1. Opens N requested pcaps/dumpers instead of N^2 2. Leak of
>> pcap/dumper's which are being overwritten by
>> the sequential calls to open_rx/tx_pcap/iface functions 3. Use the
>> filename/iface args per queue and not just the last one
>> that overwrites the previous names
>
> Please add a "Fixes: xx" line, that is to trace initial commit the issue introduced. More details in contribution guide.
> Also please add "Cc: stable@dpdk.org" to be sure patch sent to stable tree too and to help stable tree maintainers"
> [ido] as far as I can trace back this is from day one (4c17330 pcap: add new driver), Would "Fixes: 4c17330" be ok?
As commit, it looks correct, thanks. For syntax we are using a git alias for
unified syntax [1], which makes output as [2].
[1]
git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h (\"%s\")%nCc: %ae'"
[2]
Fixes: 4c173302c307 ("pcap: add new driver")
>
>>
>> Signed-off-by: ido goshen <ido@cgstowernetworks.com>
>
> <...>
>
>> @@ -958,15 +950,8 @@ struct pmd_devargs {
>> * We check whether we want to open a RX stream from a real NIC or a
>> * pcap file
>> */
>> - pcaps.num_of_queue = rte_kvargs_count(kvlist, ETH_PCAP_RX_PCAP_ARG);
>> - if (pcaps.num_of_queue)
>> - is_rx_pcap = 1;
>> - else
>> - pcaps.num_of_queue = rte_kvargs_count(kvlist,
>> - ETH_PCAP_RX_IFACE_ARG);
>> -
>> - if (pcaps.num_of_queue > RTE_PMD_PCAP_MAX_QUEUES)
>> - pcaps.num_of_queue = RTE_PMD_PCAP_MAX_QUEUES;
>> + is_rx_pcap = rte_kvargs_count(kvlist, ETH_PCAP_RX_PCAP_ARG) ? 1 : 0;
>> + pcaps.num_of_queue = 0;
>>
>> if (is_rx_pcap)
>> ret = rte_kvargs_process(kvlist, ETH_PCAP_RX_PCAP_ARG, @@ -975,6
>> +960,10 @@ struct pmd_devargs {
>> ret = rte_kvargs_process(kvlist, ETH_PCAP_RX_IFACE_ARG,
>> &open_rx_iface, &pcaps);
>>
>> + if (pcaps.num_of_queue > RTE_PMD_PCAP_MAX_QUEUES)
>> + pcaps.num_of_queue = RTE_PMD_PCAP_MAX_QUEUES;
>
> Here is late for this check. You may be already access to rx->queue[],
> tx->queue[] out of boundary at this point.
>
> You should either check this value before rte_kvargs_process(), via rte_kvargs_count(), OR you should add this check into callback functions.
> [ido] good catch - will fix that
>
>> if (ret < 0)
>> goto free_kvlist;
>>
>> @@ -982,15 +971,8 @@ struct pmd_devargs {
>> * We check whether we want to open a TX stream to a real NIC or a
>> * pcap file
>> */
>> - dumpers.num_of_queue = rte_kvargs_count(kvlist, ETH_PCAP_TX_PCAP_ARG);
>> - if (dumpers.num_of_queue)
>> - is_tx_pcap = 1;
>> - else
>> - dumpers.num_of_queue = rte_kvargs_count(kvlist,
>> - ETH_PCAP_TX_IFACE_ARG);
>> -
>> - if (dumpers.num_of_queue > RTE_PMD_PCAP_MAX_QUEUES)
>> - dumpers.num_of_queue = RTE_PMD_PCAP_MAX_QUEUES;
>> + is_tx_pcap = rte_kvargs_count(kvlist, ETH_PCAP_TX_PCAP_ARG) ? 1 : 0;
>
> Is "is_rx_pcap" or "is_tx_pcap" flags really required? Is there anything preventing have a mixture of interface and pcap in multi queue case? With the changes you are doing, I guess we can remove these checks and call following
> sequentially:
> rte_kvargs_process(kvlist, ETH_PCAP_RX_PCAP_ARG..) rte_kvargs_process(kvlist, ETH_PCAP_RX_IFACE_ARG ..) What do you think?
> [ido] nice idea - will test if they can co-exist
>
> But please be sure the fix and refactor patches are separate, so that fix patch can be backported to stable trees. But refactor patches won't be backported.
>
prev parent reply other threads:[~2018-06-19 10:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-16 15:36 ido goshen
2018-06-16 15:36 ` [dpdk-dev] [PATCH 2/2] net/pcap: duplicate code consolidation ido goshen
2018-06-18 8:25 ` [dpdk-dev] [PATCH 1/2] net/pcap: multiple queues fix Ferruh Yigit
2018-06-19 9:45 ` Ido Goshen
2018-06-19 10:00 ` Ferruh Yigit [this message]
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=9cd6a50f-719e-b0b7-f285-bd85fcf7847f@intel.com \
--to=ferruh.yigit@intel.com \
--cc=Ido@cgstowernetworks.com \
--cc=dev@dpdk.org \
/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).