From: Stephen Hemminger <stephen@networkplumber.org>
To: Long Li <longli@microsoft.com>
Cc: "longli@linuxonhyperv.com" <longli@linuxonhyperv.com>,
Wei Hu <weh@microsoft.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without monitoring enabled
Date: Wed, 12 Mar 2025 08:36:11 -0700 [thread overview]
Message-ID: <20250312083611.5d34cd99@hermes.local> (raw)
In-Reply-To: <SA6PR21MB4231702177B6AACAF54FF40DCED02@SA6PR21MB4231.namprd21.prod.outlook.com>
On Wed, 12 Mar 2025 00:33:52 +0000
Long Li <longli@microsoft.com> wrote:
> > Subject: [EXTERNAL] Re: [patch v2 0/6] Support VMBUS channels without
> > monitoring enabled
> >
> > On Mon, 10 Mar 2025 14:42:51 -0700
> > longli@linuxonhyperv.com wrote:
> >
> > > From: Long Li <longli@microsoft.com>
> > >
> > > Hyperv may expose VMBUS channels without monitoring enabled. In this
> > > case, it programs almost all the data traffic to VF.
> > >
> > > This patchset enabled vmbus/netvsc to use channels without monitoring
> > > enabled.
> >
> >
> > CI still reports a build issue
>
> There are ABI changes to rte_vmbus_* calls. This patch added rte_vmbus_device* as the 1st parameter to those calls.
>
> This will be a breaking change, and it only affects hn_netvsc as it's the only PMD using the vmbus.
>
> Reading ./doc/guides/contributing/abi_policy.rst, I think the best option is to use RTE_NEXT_ABI. But I can't find its definition in the code base.
>
> Please advise on how to proceed with making those breaking ABI changes.
>
> Thanks,
> Long
Can't take it as is, here are some options:
1. Version the API even though should only be used internally. Use API versioning
as transistion until 25.11.
2. Wait for 25.11 and just fix it now, and do deprecation notice now.
3. Mark the API's as internal (in 25.11) and do deprecation notice now.
4. Make new functions with different names, and mark old ones as deprecated, then remove in 25.11
next prev parent reply other threads:[~2025-03-12 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 21:42 longli
2025-03-10 21:42 ` [patch v2 1/6] net/netvsc: introduce private data for storing vmbus device for secondary process longli
2025-03-10 21:42 ` [patch v2 2/6] net/netvsc: introduce get_vmbus_device to get the vmbus device longli
2025-03-10 21:42 ` [patch v2 3/6] bus/vmbus: store UIO fd for secondary process longli
2025-03-10 21:42 ` [patch v2 4/6] bus/vmbus: support channels without monitoring enabled longli
2025-03-10 21:42 ` [patch v2 5/6] bus/vmbus: add rte_vmbus_device to all functions accessing vmbus longli
2025-03-10 21:42 ` [patch v2 6/6] bus/vmbus: set event for channel without monitoring support longli
2025-03-10 23:20 ` [patch v2 0/6] Support VMBUS channels without monitoring enabled Stephen Hemminger
2025-03-12 0:33 ` [EXTERNAL] " Long Li
2025-03-12 15:36 ` Stephen Hemminger [this message]
2025-03-12 21:45 ` 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=20250312083611.5d34cd99@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--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).