From: Stephen Hemminger <stephen@networkplumber.org>
To: Long Li <longli@microsoft.com>
Cc: "longli@linuxonhyperv.com" <longli@linuxonhyperv.com>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Wei Hu <weh@microsoft.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for hot plug events
Date: Tue, 28 Jan 2025 16:31:30 -0800 [thread overview]
Message-ID: <20250128163130.4e718cc2@hermes.local> (raw)
In-Reply-To: <SA6PR21MB423184289E69944273AEC587CEEE2@SA6PR21MB4231.namprd21.prod.outlook.com>
On Wed, 29 Jan 2025 00:10:12 +0000
Long Li <longli@microsoft.com> wrote:
> > Subject: [EXTERNAL] Re: [PATCH 4/4] net/netvsc: cache device parameters for
> > hot plug events
> >
> > On Mon, 27 Jan 2025 17:35:06 -0800
> > longli@linuxonhyperv.com wrote:
> >
> > > @@ -1409,9 +1424,6 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev)
> > > ret_stop = hn_dev_stop(eth_dev);
> > > hn_dev_close(eth_dev);
> > >
> > > - free(hv->vf_devargs);
> > > - hv->vf_devargs = NULL;
> > > -
> > > hn_detach(hv);
> > > hn_chim_uninit(eth_dev);
> > > rte_vmbus_chan_close(hv->channels[0]);
> > > @@ -1423,6 +1435,61 @@ eth_hn_dev_uninit(struct rte_eth_dev *eth_dev)
> > > return ret_stop;
> > > }
> > >
> > > +static int populate_cache_list(void)
> > > +{
> > > + int ret;
> > > + struct rte_devargs *da;
> > > +
> > > + rte_spinlock_lock(&netvsc_lock);
> > > + da_cache_usage++;
> > > + if (da_cache_usage > 1) {
> > > + ret = 0;
> > > + goto out;
> > > + }
> > > +
> > > + LIST_INIT(&da_cache_list);
> > > + RTE_EAL_DEVARGS_FOREACH("pci", da) {
> > > + struct da_cache *cache;
> > > +
> > > + cache = rte_zmalloc("NETVSC-HOTADD", sizeof(*cache),
> > rte_mem_page_size());
> > > + if (!cache) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > + strncpy(cache->name, da->name, sizeof(da->name));
> > > + cache->drv_str = strdup(da->drv_str);
> > > + if (!cache->drv_str) {
> > > + rte_free(cache);
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > + LIST_INSERT_HEAD(&da_cache_list, cache, list);
> > > + }
> >
> > Why do you need to cache entry to be page aligned, that seems unnecessary
> > wasteful?
>
> You are right it doesn't need to. I'm removing the alignment.
>
> > Why does it need to be huge pages? versus normal malloc?
>
> I thought it would make it easier to debug memory leaks through EAL. But normal malloc is fine because this data is not shared between primary/secondary.
>
> > The string is coming from malloc (strdup) so it can't be used by secondary process.
> >
> > Since you are allocating a devargs cache entry, you could just as well use flexible
> > array where entry was like:
> > struct da_cache {
> > LIST_ENTRY(da_cache) list;
> > char name[RTE_DEV_NAME_MAX_LEN];
> > char drv_str[];
> > };
>
> This is difficult as I don't know how big it is for drv_str[].
That is why the malloc adds extra space for drv_str, see below.
Flexible array allow one array at end of structure
> >
> >
> > cache = malloc(sizeof(*cache) + strlen(da->drv_str) + 1); ...
> > strcpy(cache->drv_str, da->drv_str);
>
> Another approach is to modify EAL to never delete driver arguments when a device is removed. i.e., It doesn't call rte_devargs_remove() on device removal, instead keep those devargs for the lifetime of the process. Do you think this is a better approach? This will save work if other drivers want to cache devargs list for device hot plug events.
Not sure, right now I don't think it is possible to pre-add devargs for future hot plug
next prev parent reply other threads:[~2025-01-29 0:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 1:35 [PATCH 1/4] net/netvsc: scan all net devices under the PCI device longli
2025-01-28 1:35 ` [PATCH 2/4] net/netvsc: remove RTE device if all its net devices are removed longli
2025-01-28 1:35 ` [PATCH 3/4] net/netvsc: log error on failure to switch data path longli
2025-01-28 1:35 ` [PATCH 4/4] net/netvsc: cache device parameters for hot plug events longli
2025-01-28 21:00 ` Stephen Hemminger
2025-01-29 0:10 ` [EXTERNAL] " Long Li
2025-01-29 0:31 ` Stephen Hemminger [this message]
2025-01-29 0:54 ` Long Li
2025-01-30 3:59 ` Stephen Hemminger
2025-01-28 21:01 ` Stephen Hemminger
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=20250128163130.4e718cc2@hermes.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=longli@linuxonhyperv.com \
--cc=longli@microsoft.com \
--cc=weh@microsoft.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).