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: 12+ 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-02-03 19:00 ` Long Li
2025-01-28 21:01 ` Stephen Hemminger
2025-02-07 22:06 ` [EXTERNAL] [PATCH 1/4] net/netvsc: scan all net devices under the PCI device Long Li
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.