From: Vlad Zolotarov <vladz@cloudius-systems.com>
To: Gleb Natapov <gleb@scylladb.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] API feature check _HAS_
Date: Sun, 29 Nov 2015 11:43:16 +0200 [thread overview]
Message-ID: <565AC8B4.7070403@cloudius-systems.com> (raw)
In-Reply-To: <20151129091011.GG19023@scylladb.com>
On 11/29/15 11:10, Gleb Natapov wrote:
> On Sun, Nov 29, 2015 at 11:07:44AM +0200, Vlad Zolotarov wrote:
>>
>> On 11/26/15 22:35, Thomas Monjalon wrote:
>>> When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
>>> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329
>>>
>>> It allows to use the feature without version check (before the release or
>>> after a backport).
>>> Do you think it is useful?
>>> Should we define other macros RTE_[API]_HAS_[FEATURE] for each new feature
>>> or API change?
>> The main purpose of the above macro was to identify the presence of the new
>> field in the rte_eth_rxmode during the
>> period of time when there was no other way to know it. Once this may be
>> concluded based on the release version I see no
>> reason to keep it.
>>
> Concluding things based on release version does not work so well for
> back ports.
In that case the existing applications won't be able to enjoy the
feature with the older releases with the backport - that's true.
Having this flag has it's benefits (e.g. the corresponding ifdefs are
much more readable), however to be consistent we'd rather define this
type of flags
for other features too like Thomas wrote above. I'm not against this
approach too...
>
>>> It's time to fix it before releasing the 2.2 version.
> --
> Gleb.
prev parent reply other threads:[~2015-11-29 9:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-26 20:35 Thomas Monjalon
2015-11-29 9:07 ` Vlad Zolotarov
2015-11-29 9:10 ` Gleb Natapov
2015-11-29 9:43 ` Vlad Zolotarov [this message]
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=565AC8B4.7070403@cloudius-systems.com \
--to=vladz@cloudius-systems.com \
--cc=dev@dpdk.org \
--cc=gleb@scylladb.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).