From: David Marchand <david.marchand@redhat.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Laurent Hardy <laurent.hardy@6wind.com>, dev <dev@dpdk.org>,
Olivier Matz <olivier.matz@6wind.com>,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <arybchenko@solarflare.com>
Subject: Re: [dpdk-dev] [PATCH] librte_ethdev: extend dpdk api led control to query capability
Date: Wed, 8 Jan 2020 14:00:43 +0100 [thread overview]
Message-ID: <CAJFAV8wqYfXNQY1Gjnrb_R-cnD=PJ+FjqjQJsKF4eO8dD3V5vw@mail.gmail.com> (raw)
In-Reply-To: <27a90969-0241-00e0-0748-b6c6327ab4db@intel.com>
On Wed, Jan 8, 2020 at 1:30 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 1/8/2020 9:55 AM, David Marchand wrote:
> > On Wed, Jan 8, 2020 at 10:09 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >> Why it is an ABI break, dev_ops should be between library and drivers, so it
> >> should be out of the ABI concern, isn't it.
> >
> > You are right.
> > So in our context, this is not an ABI breakage.
> > But abidiff still reports it, so maybe some filtering is required to
> > avoid this false positive.
> >
> > Note that if we insert an ops before rx_queue_count, we would have a
> > real ABI breakage, as this ops is accessed via an inline wrapper by
> > applications.
> >
>
> This is good point, perhaps we should add a comment to that line to highlight it.
The comment won't help in the CI checks.
Not talking about short term, but could we consider separating the
inlined ops from the rest (pushing them to rte_eth_dev ?) ?
We would then hide completely eth_dev_ops at the next ABI break window.
--
David Marchand
next prev parent reply other threads:[~2020-01-08 13:00 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 14:56 Laurent Hardy
2020-01-08 8:56 ` David Marchand
2020-01-08 9:09 ` Ferruh Yigit
2020-01-08 9:42 ` Olivier Matz
2020-01-08 12:12 ` Ferruh Yigit
2020-01-08 12:27 ` Olivier Matz
2020-01-08 14:08 ` Ferruh Yigit
2020-01-08 14:45 ` Laurent Hardy
2020-01-08 9:55 ` David Marchand
2020-01-08 10:31 ` Laurent Hardy
2020-01-08 12:59 ` Ferruh Yigit
2020-01-08 13:06 ` Thomas Monjalon
2020-01-08 13:20 ` Ferruh Yigit
2020-01-08 13:25 ` Thomas Monjalon
2020-01-08 13:34 ` Thomas Monjalon
2020-01-08 13:53 ` Ferruh Yigit
2020-01-08 13:52 ` Ferruh Yigit
2020-01-08 14:01 ` Ferruh Yigit
2020-01-08 14:15 ` Andrew Rybchenko
2020-01-08 14:27 ` Thomas Monjalon
2020-01-08 14:37 ` Andrew Rybchenko
2020-01-08 13:58 ` Laurent Hardy
2020-01-08 14:07 ` Thomas Monjalon
2020-01-08 15:16 ` Laurent Hardy
2020-05-08 12:03 ` Ferruh Yigit
2020-05-08 12:11 ` Ferruh Yigit
2020-01-08 12:30 ` Ferruh Yigit
2020-01-08 13:00 ` David Marchand [this message]
2020-01-08 13:11 ` 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='CAJFAV8wqYfXNQY1Gjnrb_R-cnD=PJ+FjqjQJsKF4eO8dD3V5vw@mail.gmail.com' \
--to=david.marchand@redhat.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=laurent.hardy@6wind.com \
--cc=olivier.matz@6wind.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).