DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] API feature check _HAS_
@ 2015-11-26 20:35 Thomas Monjalon
  2015-11-29  9:07 ` Vlad Zolotarov
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Monjalon @ 2015-11-26 20:35 UTC (permalink / raw)
  To: dev

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?
It's time to fix it before releasing the 2.2 version.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] API feature check _HAS_
  2015-11-26 20:35 [dpdk-dev] API feature check _HAS_ Thomas Monjalon
@ 2015-11-29  9:07 ` Vlad Zolotarov
  2015-11-29  9:10   ` Gleb Natapov
  0 siblings, 1 reply; 4+ messages in thread
From: Vlad Zolotarov @ 2015-11-29  9:07 UTC (permalink / raw)
  To: Thomas Monjalon, dev



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.

> It's time to fix it before releasing the 2.2 version.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] API feature check _HAS_
  2015-11-29  9:07 ` Vlad Zolotarov
@ 2015-11-29  9:10   ` Gleb Natapov
  2015-11-29  9:43     ` Vlad Zolotarov
  0 siblings, 1 reply; 4+ messages in thread
From: Gleb Natapov @ 2015-11-29  9:10 UTC (permalink / raw)
  To: Vlad Zolotarov; +Cc: dev

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.

> >It's time to fix it before releasing the 2.2 version.
> 

--
			Gleb.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [dpdk-dev] API feature check _HAS_
  2015-11-29  9:10   ` Gleb Natapov
@ 2015-11-29  9:43     ` Vlad Zolotarov
  0 siblings, 0 replies; 4+ messages in thread
From: Vlad Zolotarov @ 2015-11-29  9:43 UTC (permalink / raw)
  To: Gleb Natapov; +Cc: dev



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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-11-29  9:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-26 20:35 [dpdk-dev] API feature check _HAS_ Thomas Monjalon
2015-11-29  9:07 ` Vlad Zolotarov
2015-11-29  9:10   ` Gleb Natapov
2015-11-29  9:43     ` Vlad Zolotarov

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).