DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wiles, Keith" <keith.wiles@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Raslan Darawsheh <rasland@mellanox.com>,
	"ophirmu@mellanox.com" <ophirmu@mellanox.com>
Subject: Re: [dpdk-dev] [PATCH v3] net/tap: add queues when attaching from secondary process
Date: Sat, 21 Jul 2018 13:44:41 +0000	[thread overview]
Message-ID: <0EAF8388-4F19-4258-85FD-C18CFCCCE7BE@intel.com> (raw)
In-Reply-To: <2122883.JrNZV5Vflb@xps>



> On Jul 20, 2018, at 4:51 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> 20/07/2018 17:35, Wiles, Keith:
>>> On Jul 20, 2018, at 4:15 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>>> +	/* FIXME: handle replies.nb_received > 1 */
>> 
>> I am not a big fan of having TODO or FIXME comments in the code.
> 
> What don't you like in such comments?

We should not have FIXME or TODO in the code it does not look like it is complete, if we need to fix something then fix it or put it on a todo list not in the code. The same thing for the TODO which to me means a future enhancement we just need to add it to a future todo list.

If the code in these sections have a limitation them describe the limitation and remove the FIXME and TODOs from the code.

> 
>> Can we remove them and just describe the problem and what would happen
>> or not happen if the condition occurs?
> 
> You mean describing the problem in the code?
> 
>> If we need to add this support in the future then we need to put these
>> in a enhancement tracker or someplace else.
> 
> The limitation is documented in the guide (limit of 8 queues).
> 
>>> +	reply = &replies.msgs[0];
> 
> [...]
>>> +	/* FIXME: split message if more queues than RTE_MP_MAX_FD_NUM */
>> 
>> Here too.
> 
> This limitation is related to the previous one (send only one message,
> receive only message).
> 
>>> +	RTE_ASSERT(reply.num_fds <= RTE_MP_MAX_FD_NUM);
>>> +
>>> +	/* Send reply */
>>> +	strcpy(reply.name, request->name);
>>> +	strcpy(reply_param->port_name, request_param->port_name);
>> 
>> Normally we use the snprintf or strlcpy() functions for the above should we do that here too?
> 
> Yes it looks to be a good idea.
> 
> 
>>> @@ -1946,8 +2056,18 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev)
>>> 			TAP_LOG(ERR, "Failed to probe %s", name);
>>> 			return -1;
>>> 		}
>>> -		/* TODO: request info from primary to set up Rx and Tx */
>>> 		eth_dev->dev_ops = &ops;
>>> +		eth_dev->rx_pkt_burst = pmd_rx_burst;
>>> +		eth_dev->tx_pkt_burst = pmd_tx_burst;
>>> +
>>> +		if (!rte_eal_primary_proc_alive(NULL)) {
>>> +			TAP_LOG(ERR, "Primary process is missing");
>>> +			return -1;
>>> +		}
>>> +		ret = tap_mp_attach_queues(name, eth_dev);
>>> +		if (ret != 0)
>>> +			return -1;
>> 
>> Does the call above need to be wrapped using if secondary process or is this for both primary and secondary?
> 
> It is already in a "secondary only" block.
> 
>>> +	/* Register IPC feed callback */
>>> +	ret = rte_mp_action_register(TAP_MP_KEY, tap_mp_sync_queues);
>>> +	if (ret < 0 && rte_errno != EEXIST) {
>>> +		TAP_LOG(ERR, "%s: Failed to register IPC callback: %s",
>>> +			tuntap_name, strerror(rte_errno));
>>> +		goto leave;
>>> +	}
>> 
>> Same for this one as above?
> 
> This code path is executed only in primary or creation of port in secondary.
> I think it is fine.
> 
> However I am thinking it should be registered only once for all TAP ports.
> 
> 

Regards,
Keith

  reply	other threads:[~2018-07-21 13:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 12:29 [dpdk-dev] [RFC] " Raslan Darawsheh
2018-06-07 19:09 ` Wiles, Keith
2018-06-07 23:24   ` Raslan Darawsheh
2018-06-08  2:52     ` Wiles, Keith
2018-06-12 12:46     ` Wiles, Keith
2018-06-12 13:21       ` Raslan Darawsheh
2018-07-20 10:57 ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2018-09-27 11:19   ` [dpdk-dev] [PATCH v3 1/2] net/tap: change queue fd to be pointers to process private Raslan Darawsheh
2018-09-27 11:19     ` [dpdk-dev] [PATCH v3 2/2] net/tap: add queues when attaching from secondary process Raslan Darawsheh
2018-09-27 13:04       ` Wiles, Keith
2018-09-27 18:53         ` Thomas Monjalon
2018-10-02 10:34       ` [dpdk-dev] [PATCH v4 1/2] net/tap: change queue fd to be pointers to process private Raslan Darawsheh
2018-10-02 10:34         ` [dpdk-dev] [PATCH v4 2/2] net/tap: add queues when attaching from secondary process Raslan Darawsheh
2018-10-02 10:41           ` Thomas Monjalon
2018-10-02 10:50             ` Raslan Darawsheh
2018-10-02 11:38               ` Thomas Monjalon
2018-10-03 16:28                 ` Ferruh Yigit
2018-10-02 10:43           ` Thomas Monjalon
2018-10-03 16:31             ` Ferruh Yigit
2018-10-03 18:00           ` Ferruh Yigit
2018-10-03 17:59         ` [dpdk-dev] [PATCH v4 1/2] net/tap: change queue fd to be pointers to process private Ferruh Yigit
2018-09-27 13:17     ` [dpdk-dev] [PATCH v3 " Wiles, Keith
2018-10-02 10:30       ` Raslan Darawsheh
2018-10-02 12:58         ` Wiles, Keith
2018-10-03 17:27           ` Ferruh Yigit
2018-07-20 11:15 ` [dpdk-dev] [PATCH v3] net/tap: add queues when attaching from secondary process Thomas Monjalon
2018-07-20 15:35   ` Wiles, Keith
2018-07-20 21:51     ` Thomas Monjalon
2018-07-21 13:44       ` Wiles, Keith [this message]
2018-08-23 11:51   ` 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=0EAF8388-4F19-4258-85FD-C18CFCCCE7BE@intel.com \
    --to=keith.wiles@intel.com \
    --cc=dev@dpdk.org \
    --cc=ophirmu@mellanox.com \
    --cc=rasland@mellanox.com \
    --cc=thomas@monjalon.net \
    /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).