* Re: [dpdk-dev] ABI and inline functions
2019-04-17 16:52 4% ` Stephen Hemminger
@ 2019-04-17 16:52 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 16:52 UTC (permalink / raw)
To: Bruce Richardson
Cc: Honnappa Nagarahalli, dev, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 09:36:38 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage
> some changes without breaking ABI.
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also send
> > the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should
> not be a massive issue, I hope. On the other hand, ABI compatibility is
> needed to allow seamless update from one version to another, and it's that
> ABI compatiblity that allows distro's to pick up our latest and greatest
> versions.
Agree with Bruce. What is most important about API is that the function
should change signature if behavior changes. I.e catch API changes at
compile time (not runtime).
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
@ 2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-17 16:52 UTC (permalink / raw)
To: Bruce Richardson
Cc: Honnappa Nagarahalli, dev, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 09:36:38 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
> >
> I disagree. I think even in the case of #1, we should be able to manage
> some changes without breaking ABI.
>
> > In this context, does it make sense to say that we will maintain API
> > compatibility rather than saying ABI compatibility? This will also send
> > the right message to the end users.
> >
> I would value ABI compatibility much higher than API compatibility. If
> someone is recompiling the application anyway, making a couple of small
> changes (large rework is obviously a different issue) to the code should
> not be a massive issue, I hope. On the other hand, ABI compatibility is
> needed to allow seamless update from one version to another, and it's that
> ABI compatiblity that allows distro's to pick up our latest and greatest
> versions.
Agree with Bruce. What is most important about API is that the function
should change signature if behavior changes. I.e catch API changes at
compile time (not runtime).
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 14:18 0% ` Thomas Monjalon
@ 2019-04-17 14:18 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-17 14:18 UTC (permalink / raw)
To: Ananyev, Konstantin, Honnappa Nagarahalli, Stephen Hemminger
Cc: dev, paulmck, Kovacevic, Marko, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
17/04/2019 15:39, Ananyev, Konstantin:
> In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
> and then figure out that no-one using them because they are too slow.
> Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
> (as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
> If we'll find there is no real difference - move it to not-inlined version in 19.08.
> It is experimental for now - so could be changed without formal ABI breakage.
I agree, it looks reasonnable to take v6 of RCU patches
as an experimental implementation.
Then we can run some tests and discuss about inlining or not
before promoting it as a stable API.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
@ 2019-04-17 14:18 0% ` Thomas Monjalon
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-17 14:18 UTC (permalink / raw)
To: Ananyev, Konstantin, Honnappa Nagarahalli, Stephen Hemminger
Cc: dev, paulmck, Kovacevic, Marko, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
17/04/2019 15:39, Ananyev, Konstantin:
> In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
> and then figure out that no-one using them because they are too slow.
> Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
> (as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
> If we'll find there is no real difference - move it to not-inlined version in 19.08.
> It is experimental for now - so could be changed without formal ABI breakage.
I agree, it looks reasonnable to take v6 of RCU patches
as an experimental implementation.
Then we can run some tests and discuss about inlining or not
before promoting it as a stable API.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 14:02 0% ` Honnappa Nagarahalli
@ 2019-04-17 14:02 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 14:02 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > > > >
> > > > > > > > > > > > > After evaluating long term API/ABI issues, I
> > > > > > > > > > > > > think you need to get rid of almost all use of
> > > > > > > > > > > > > inline and visible structures. Yes it might be
> > > > > > > > > > > > > marginally slower, but you thank me
> > > > > > > the first time you have to fix something.
> > > > > > > > > > > > >
> > > > > > > > > > > > Agree, I was planning on another version to
> > > > > > > > > > > > address this (I am yet
> > > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > > The structure visibility definitely needs to be
> addressed.
> > > > > > > > > > > > For the inline functions, is the plan to convert
> > > > > > > > > > > > all the inline functions in DPDK? If yes, I think
> > > > > > > > > > > > we need to consider the performance
> > > > > > > > > > > difference. May be consider L3-fwd application,
> > > > > > > > > > > change all the
> > > > > > > inline functions in its path and run a test?
> > > > > > > > > > >
> > > > > > > > > > > Every function that is not in the direct datapath
> > > > > > > > > > > should not be
> > > > > > > inline.
> > > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > > have
> > > > > inline functions (unless we freeze any development in these
> > > > > inline functions forever).
> > > > > >
> > > > > > > > > >
> > > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > > I think rcu should be one of such exceptions - it is
> > > > > > > > > > just another synchronization mechanism after all (just
> > > > > > > > > > a bit more
> > > > > sophisticated).
> > > > > > > > > > Konstantin
> > > > > > > > >
> > > > > > > > > If you look at the other userspace RCU, you wil see that
> > > > > > > > > the only inlines are the rcu_read_lock,rcu_read_unlock
> > > > > > > > > and
> > > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > > >
> > > > > > > > > The synchronization logic is all real functions.
> > > > > > > >
> > > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > > https://github.com/urcu/userspace-
> > > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > > urcu-qsbr.h I still don't understand why we have to treat
> > > > > > > > it differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > > If we gone all the way to create our own version of rcu,
> > > > > > > > we probably want it to be as fast as possible (I know that
> > > > > > > > main speedup should come from the fact that readers don't
> > > > > > > > have to wait for writer to finish, but still...)
> > > > > > > >
> > > > > > > > Konstantin
> > > > > > > >
> > > > > > >
> > > > > > > Having locking functions inline is already a problem in
> > > > > > > current
> > > releases.
> > > > > > > The implementation can not be improved without breaking ABI
> > > > > > > (or doing special workarounds like lock v2)
> > > > > > I think ABI and inline function discussion needs to be taken
> > > > > > up in a
> > > > > different thread.
> > > > > >
> > > > > > Currently, I am looking to hide the structure visibility. I
> > > > > > looked at your
> > > > > patch [1], it is a different case than what I have in this
> > > > > patch. It is a pretty generic use case as well (similar
> > > > > situation exists in other libraries). I think a generic solution should
> be agreed upon.
> > > > > >
> > > > > > If we have to hide the structure content, the handle to QS
> > > > > > variable
> > > > > returned to the application needs to be opaque. I suggest using
> 'void *'
> > > > > behind which any structure can be used.
> > > > > >
> > > > > > typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t;
> > > > > >
> > > > > > But it requires typecasting.
> > > > > >
> > > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > > >
> > > > > C allows structure to be defined without knowing what is in it
> > > therefore.
> > > > >
> > > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > > >
> > > > > is preferred (or do it without typedef)
> > > > >
> > > > > struct rte_rcu_qsbr;
> > > >
> > > > I see that rte_hash library uses the same approach (struct
> > > > rte_hash in
> > > rte_hash.h, though it is marking as internal). But the ABI
> > > Laboratory tool [1] seems to be reporting incorrect numbers for this
> > > library even though the internal structure is changed.
> > > >
> > > > [1]
> > > > https://abi-
> > > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > > 2&v2=current&obj=66794&kind=abi
> > >
> > > The problem is rte_hash structure is exposed as part of ABI in
> > > rte_cuckoo_hash.h This was a mistake.
> > Do you mean, due to the use of structure with the same name? I am
> > wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
> >
> > For the RCU library, we either need to go all functions or leave it
> > the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
> >
> > I converted the inline functions to function calls.
> >
> > Testing on Arm platform (results *are* repeatable) shows very minimal
> > drop (0.1% to 0.2%) in performance while using lock-free rte_hash data
> structure. But one of the test cases which is just spinning shows good
> amount of drop (41%).
> >
> > Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty
> > repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning
> show significant drop (14%, 155%, 231%).
> > Konstantin, any thoughts on the results?
>
> The fact that function show better result than inline (even for hash) is sort
> of surprise to me.
It was a surprise to me too and counter-intuitive to my understanding.
> Don't have any good explanation off-hand, but the actual numbers for
> hash test are huge by itself...
>
> In general, I still think that sync primitives better to stay inlined - there is
> no much point to create ones and then figure out that no-one using them
> because they are too slow.
> Though if there is no real perf difference between inlined and normal - no
> point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do
> further perf testing with it (as I remember there were suggestions about
> using it in l3fwd for guarding routing table or so).
Yes, there is more work planned to integrate the library better which might provide more insight.
> If we'll find there is no real difference - move it to not-inlined version in
> 19.08.
+1.
> It is experimental for now - so could be changed without formal ABI
> breakage.
>
> Konstantin
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
@ 2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 14:02 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > > > >
> > > > > > > > > > > > > After evaluating long term API/ABI issues, I
> > > > > > > > > > > > > think you need to get rid of almost all use of
> > > > > > > > > > > > > inline and visible structures. Yes it might be
> > > > > > > > > > > > > marginally slower, but you thank me
> > > > > > > the first time you have to fix something.
> > > > > > > > > > > > >
> > > > > > > > > > > > Agree, I was planning on another version to
> > > > > > > > > > > > address this (I am yet
> > > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > > The structure visibility definitely needs to be
> addressed.
> > > > > > > > > > > > For the inline functions, is the plan to convert
> > > > > > > > > > > > all the inline functions in DPDK? If yes, I think
> > > > > > > > > > > > we need to consider the performance
> > > > > > > > > > > difference. May be consider L3-fwd application,
> > > > > > > > > > > change all the
> > > > > > > inline functions in its path and run a test?
> > > > > > > > > > >
> > > > > > > > > > > Every function that is not in the direct datapath
> > > > > > > > > > > should not be
> > > > > > > inline.
> > > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > > have
> > > > > inline functions (unless we freeze any development in these
> > > > > inline functions forever).
> > > > > >
> > > > > > > > > >
> > > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > > I think rcu should be one of such exceptions - it is
> > > > > > > > > > just another synchronization mechanism after all (just
> > > > > > > > > > a bit more
> > > > > sophisticated).
> > > > > > > > > > Konstantin
> > > > > > > > >
> > > > > > > > > If you look at the other userspace RCU, you wil see that
> > > > > > > > > the only inlines are the rcu_read_lock,rcu_read_unlock
> > > > > > > > > and
> > > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > > >
> > > > > > > > > The synchronization logic is all real functions.
> > > > > > > >
> > > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > > https://github.com/urcu/userspace-
> > > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > > urcu-qsbr.h I still don't understand why we have to treat
> > > > > > > > it differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > > If we gone all the way to create our own version of rcu,
> > > > > > > > we probably want it to be as fast as possible (I know that
> > > > > > > > main speedup should come from the fact that readers don't
> > > > > > > > have to wait for writer to finish, but still...)
> > > > > > > >
> > > > > > > > Konstantin
> > > > > > > >
> > > > > > >
> > > > > > > Having locking functions inline is already a problem in
> > > > > > > current
> > > releases.
> > > > > > > The implementation can not be improved without breaking ABI
> > > > > > > (or doing special workarounds like lock v2)
> > > > > > I think ABI and inline function discussion needs to be taken
> > > > > > up in a
> > > > > different thread.
> > > > > >
> > > > > > Currently, I am looking to hide the structure visibility. I
> > > > > > looked at your
> > > > > patch [1], it is a different case than what I have in this
> > > > > patch. It is a pretty generic use case as well (similar
> > > > > situation exists in other libraries). I think a generic solution should
> be agreed upon.
> > > > > >
> > > > > > If we have to hide the structure content, the handle to QS
> > > > > > variable
> > > > > returned to the application needs to be opaque. I suggest using
> 'void *'
> > > > > behind which any structure can be used.
> > > > > >
> > > > > > typedef void * rte_rcu_qsbr_t; typedef void * rte_hash_t;
> > > > > >
> > > > > > But it requires typecasting.
> > > > > >
> > > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > > >
> > > > > C allows structure to be defined without knowing what is in it
> > > therefore.
> > > > >
> > > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > > >
> > > > > is preferred (or do it without typedef)
> > > > >
> > > > > struct rte_rcu_qsbr;
> > > >
> > > > I see that rte_hash library uses the same approach (struct
> > > > rte_hash in
> > > rte_hash.h, though it is marking as internal). But the ABI
> > > Laboratory tool [1] seems to be reporting incorrect numbers for this
> > > library even though the internal structure is changed.
> > > >
> > > > [1]
> > > > https://abi-
> > > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > > 2&v2=current&obj=66794&kind=abi
> > >
> > > The problem is rte_hash structure is exposed as part of ABI in
> > > rte_cuckoo_hash.h This was a mistake.
> > Do you mean, due to the use of structure with the same name? I am
> > wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
> >
> > For the RCU library, we either need to go all functions or leave it
> > the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
> >
> > I converted the inline functions to function calls.
> >
> > Testing on Arm platform (results *are* repeatable) shows very minimal
> > drop (0.1% to 0.2%) in performance while using lock-free rte_hash data
> structure. But one of the test cases which is just spinning shows good
> amount of drop (41%).
> >
> > Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty
> > repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning
> show significant drop (14%, 155%, 231%).
> > Konstantin, any thoughts on the results?
>
> The fact that function show better result than inline (even for hash) is sort
> of surprise to me.
It was a surprise to me too and counter-intuitive to my understanding.
> Don't have any good explanation off-hand, but the actual numbers for
> hash test are huge by itself...
>
> In general, I still think that sync primitives better to stay inlined - there is
> no much point to create ones and then figure out that no-one using them
> because they are too slow.
> Though if there is no real perf difference between inlined and normal - no
> point to keep it inlined.
> About RCU lib, my thought to have inlined version for 19.05 and do
> further perf testing with it (as I remember there were suggestions about
> using it in l3fwd for guarding routing table or so).
Yes, there is more work planned to integrate the library better which might provide more insight.
> If we'll find there is no real difference - move it to not-inlined version in
> 19.08.
+1.
> It is experimental for now - so could be changed without formal ABI
> breakage.
>
> Konstantin
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 13:39 3% ` Ananyev, Konstantin
@ 2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-17 13:39 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
> > > > > > > > > > > >
> > > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > > slower, but you thank me
> > > > > > the first time you have to fix something.
> > > > > > > > > > > >
> > > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > > this (I am yet
> > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > > to consider the performance
> > > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > > all the
> > > > > > inline functions in its path and run a test?
> > > > > > > > > >
> > > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > > not be
> > > > > > inline.
> > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > have
> > > > inline functions (unless we freeze any development in these inline
> > > > functions forever).
> > > > >
> > > > > > > > >
> > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > > more
> > > > sophisticated).
> > > > > > > > > Konstantin
> > > > > > > >
> > > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > >
> > > > > > > > The synchronization logic is all real functions.
> > > > > > >
> > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > https://github.com/urcu/userspace-
> > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > > probably want it to be as fast as possible (I know that main
> > > > > > > speedup should come from the fact that readers don't have to
> > > > > > > wait for writer to finish, but still...)
> > > > > > >
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Having locking functions inline is already a problem in current
> > releases.
> > > > > > The implementation can not be improved without breaking ABI (or
> > > > > > doing special workarounds like lock v2)
> > > > > I think ABI and inline function discussion needs to be taken up in
> > > > > a
> > > > different thread.
> > > > >
> > > > > Currently, I am looking to hide the structure visibility. I looked
> > > > > at your
> > > > patch [1], it is a different case than what I have in this patch. It
> > > > is a pretty generic use case as well (similar situation exists in
> > > > other libraries). I think a generic solution should be agreed upon.
> > > > >
> > > > > If we have to hide the structure content, the handle to QS
> > > > > variable
> > > > returned to the application needs to be opaque. I suggest using 'void *'
> > > > behind which any structure can be used.
> > > > >
> > > > > typedef void * rte_rcu_qsbr_t;
> > > > > typedef void * rte_hash_t;
> > > > >
> > > > > But it requires typecasting.
> > > > >
> > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > >
> > > > C allows structure to be defined without knowing what is in it
> > therefore.
> > > >
> > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > >
> > > > is preferred (or do it without typedef)
> > > >
> > > > struct rte_rcu_qsbr;
> > >
> > > I see that rte_hash library uses the same approach (struct rte_hash in
> > rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> > [1] seems to be reporting incorrect numbers for this library even though
> > the internal structure is changed.
> > >
> > > [1]
> > > https://abi-
> > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > 2&v2=current&obj=66794&kind=abi
> >
> > The problem is rte_hash structure is exposed as part of ABI in
> > rte_cuckoo_hash.h This was a mistake.
> Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
>
> For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
>
> I converted the inline functions to function calls.
>
> Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash
> data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
>
> Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
> Konstantin, any thoughts on the results?
The fact that function show better result than inline (even for hash) is sort of surprise to me.
Don't have any good explanation off-hand, but the actual numbers for hash test are huge by itself...
In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
and then figure out that no-one using them because they are too slow.
Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
(as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
If we'll find there is no real difference - move it to not-inlined version in 19.08.
It is experimental for now - so could be changed without formal ABI breakage.
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
@ 2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-17 13:39 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
> > > > > > > > > > > >
> > > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > > slower, but you thank me
> > > > > > the first time you have to fix something.
> > > > > > > > > > > >
> > > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > > this (I am yet
> > > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > > to consider the performance
> > > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > > all the
> > > > > > inline functions in its path and run a test?
> > > > > > > > > >
> > > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > > not be
> > > > > > inline.
> > > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > > have
> > > > inline functions (unless we freeze any development in these inline
> > > > functions forever).
> > > > >
> > > > > > > > >
> > > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > > more
> > > > sophisticated).
> > > > > > > > > Konstantin
> > > > > > > >
> > > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > > rcu_reference/rcu_assign_pointer.
> > > > > > > >
> > > > > > > > The synchronization logic is all real functions.
> > > > > > >
> > > > > > > In fact, I think urcu provides both flavors:
> > > > > > > https://github.com/urcu/userspace-
> > > > > > rcu/blob/master/include/urcu/static/
> > > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > > probably want it to be as fast as possible (I know that main
> > > > > > > speedup should come from the fact that readers don't have to
> > > > > > > wait for writer to finish, but still...)
> > > > > > >
> > > > > > > Konstantin
> > > > > > >
> > > > > >
> > > > > > Having locking functions inline is already a problem in current
> > releases.
> > > > > > The implementation can not be improved without breaking ABI (or
> > > > > > doing special workarounds like lock v2)
> > > > > I think ABI and inline function discussion needs to be taken up in
> > > > > a
> > > > different thread.
> > > > >
> > > > > Currently, I am looking to hide the structure visibility. I looked
> > > > > at your
> > > > patch [1], it is a different case than what I have in this patch. It
> > > > is a pretty generic use case as well (similar situation exists in
> > > > other libraries). I think a generic solution should be agreed upon.
> > > > >
> > > > > If we have to hide the structure content, the handle to QS
> > > > > variable
> > > > returned to the application needs to be opaque. I suggest using 'void *'
> > > > behind which any structure can be used.
> > > > >
> > > > > typedef void * rte_rcu_qsbr_t;
> > > > > typedef void * rte_hash_t;
> > > > >
> > > > > But it requires typecasting.
> > > > >
> > > > > [1] http://patchwork.dpdk.org/cover/52609/
> > > >
> > > > C allows structure to be defined without knowing what is in it
> > therefore.
> > > >
> > > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > > >
> > > > is preferred (or do it without typedef)
> > > >
> > > > struct rte_rcu_qsbr;
> > >
> > > I see that rte_hash library uses the same approach (struct rte_hash in
> > rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> > [1] seems to be reporting incorrect numbers for this library even though
> > the internal structure is changed.
> > >
> > > [1]
> > > https://abi-
> > laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > > 2&v2=current&obj=66794&kind=abi
> >
> > The problem is rte_hash structure is exposed as part of ABI in
> > rte_cuckoo_hash.h This was a mistake.
> Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to
> include rte_cuckoo_hash.h.
>
> For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure
> while having inline functions.
>
> I converted the inline functions to function calls.
>
> Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash
> data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
>
> Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using
> lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
> Konstantin, any thoughts on the results?
The fact that function show better result than inline (even for hash) is sort of surprise to me.
Don't have any good explanation off-hand, but the actual numbers for hash test are huge by itself...
In general, I still think that sync primitives better to stay inlined - there is no much point to create ones
and then figure out that no-one using them because they are too slow.
Though if there is no real perf difference between inlined and normal - no point to keep it inlined.
About RCU lib, my thought to have inlined version for 19.05 and do further perf testing with it
(as I remember there were suggestions about using it in l3fwd for guarding routing table or so).
If we'll find there is no real difference - move it to not-inlined version in 19.08.
It is experimental for now - so could be changed without formal ABI breakage.
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 9% ` Bruce Richardson
@ 2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-17 8:36 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> Hello,
> There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
>
Thanks for kicking off this discussion
> 1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
I agree that in some cases the application "might" need to be recompiled,
but on the other hand I also think that there are many cases where ABI
function versioning can still be used to mitigate things. For example, if
we think of a couple of various scenarios:
1. If everything is inline and variables are allocated by app, e.g.
spinlock on stack, then there is no issue as everything is application
contained.
2. If the situation is as in #1, but the structures in question are passed
to non-inline DPDK functions. In this case, any changes to the structures
require those functions taking the structures to be versioned for old and
new structures
3. If instead we have the case, like in rte_ring, where the data structures
are allocated using functions, but they are used via inlines in the app. In
this case the creation functions (and any other function using the
structures) need to be versioned so that the application gets the expected
structure back from the creation.
It might be useful to think of what other scenarios we have and what ones
are likely to be problematic, especially those that can't be solved by
having multiple function versions.
> 2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
Agree with this. Anything not data path should not be inline. The next
question then is for data path items how to determine whether they need to
be inline or not. In general my rule-of-thumb:
* anything dealing with bursts of packets should not be inline
* anything what works with single packet at a time should be inline
The one exception to this rule is cases where we have to consider "empty
polling" as a likely use-case. For example, rte_ring_dequeue_burst works
with bursts of packets, but there is a valid application use case where a
thread could be polling a set of rings where only a small number are
actually busy. Right now, polling an empty ring only costs a few cycles,
meaning that it's neglible to have a few polls of empty rings before you
get to a busy one. Having that function not-inline will cause that cost to
jump significantly, so could cause problems. (This leads to the interesting
scenario where ring enqueue is safe to un-inline, while dequeue is not).
> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
>
In general I believe the synchronisation primitives should be inline.
However, it does come down to cost too - if a function takes 300 cycles, do
we really care if it takes 305 or 310 instead to make it not inline?
Hopefully most synchronisation primitives are faster than this so this
situation should not occur.
> 2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
>
> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
>
I disagree. I think even in the case of #1, we should be able to manage
some changes without breaking ABI.
> In this context, does it make sense to say that we will maintain API
> compatibility rather than saying ABI compatibility? This will also send
> the right message to the end users.
>
I would value ABI compatibility much higher than API compatibility. If
someone is recompiling the application anyway, making a couple of small
changes (large rework is obviously a different issue) to the code should
not be a massive issue, I hope. On the other hand, ABI compatibility is
needed to allow seamless update from one version to another, and it's that
ABI compatiblity that allows distro's to pick up our latest and greatest
versions.
Personally, I'd be happy enough to allow API changes at any point without
deprecation notice, so long as function versioning is used to ensure ABI
compatibility is kept.
My 2c.
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
@ 2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2019-04-17 8:36 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli wrote:
> Hello,
> There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
>
Thanks for kicking off this discussion
> 1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
I agree that in some cases the application "might" need to be recompiled,
but on the other hand I also think that there are many cases where ABI
function versioning can still be used to mitigate things. For example, if
we think of a couple of various scenarios:
1. If everything is inline and variables are allocated by app, e.g.
spinlock on stack, then there is no issue as everything is application
contained.
2. If the situation is as in #1, but the structures in question are passed
to non-inline DPDK functions. In this case, any changes to the structures
require those functions taking the structures to be versioned for old and
new structures
3. If instead we have the case, like in rte_ring, where the data structures
are allocated using functions, but they are used via inlines in the app. In
this case the creation functions (and any other function using the
structures) need to be versioned so that the application gets the expected
structure back from the creation.
It might be useful to think of what other scenarios we have and what ones
are likely to be problematic, especially those that can't be solved by
having multiple function versions.
> 2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
Agree with this. Anything not data path should not be inline. The next
question then is for data path items how to determine whether they need to
be inline or not. In general my rule-of-thumb:
* anything dealing with bursts of packets should not be inline
* anything what works with single packet at a time should be inline
The one exception to this rule is cases where we have to consider "empty
polling" as a likely use-case. For example, rte_ring_dequeue_burst works
with bursts of packets, but there is a valid application use case where a
thread could be polling a set of rings where only a small number are
actually busy. Right now, polling an empty ring only costs a few cycles,
meaning that it's neglible to have a few polls of empty rings before you
get to a busy one. Having that function not-inline will cause that cost to
jump significantly, so could cause problems. (This leads to the interesting
scenario where ring enqueue is safe to un-inline, while dequeue is not).
> 3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
>
In general I believe the synchronisation primitives should be inline.
However, it does come down to cost too - if a function takes 300 cycles, do
we really care if it takes 305 or 310 instead to make it not inline?
Hopefully most synchronisation primitives are faster than this so this
situation should not occur.
> 2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
>
> Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
>
I disagree. I think even in the case of #1, we should be able to manage
some changes without breaking ABI.
> In this context, does it make sense to say that we will maintain API
> compatibility rather than saying ABI compatibility? This will also send
> the right message to the end users.
>
I would value ABI compatibility much higher than API compatibility. If
someone is recompiling the application anyway, making a couple of small
changes (large rework is obviously a different issue) to the code should
not be a massive issue, I hope. On the other hand, ABI compatibility is
needed to allow seamless update from one version to another, and it's that
ABI compatiblity that allows distro's to pick up our latest and greatest
versions.
Personally, I'd be happy enough to allow API changes at any point without
deprecation notice, so long as function versioning is used to ensure ABI
compatibility is kept.
My 2c.
/Bruce
^ permalink raw reply [relevance 9%]
* [dpdk-dev] ABI and inline functions
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
@ 2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 5:12 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ananyev, Konstantin; +Cc: thomas, Ray Kinsella, nd, nd
Hello,
There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
In this context, does it make sense to say that we will maintain API compatibility rather than saying ABI compatibility? This will also send the right message to the end users.
Thank you,
Honnappa
[1] http://mails.dpdk.org/archives/dev/2019-April/130151.html
^ permalink raw reply [relevance 9%]
* [dpdk-dev] ABI and inline functions
@ 2019-04-17 5:12 9% Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 5:12 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ananyev, Konstantin; +Cc: thomas, Ray Kinsella, nd, nd
Hello,
There was a conversation [1] in the context of RCU library. I thought it needs participation from broader audience. Summary for the context (please look at [1] for full details)
1) How do we provide ABI compatibility when the code base contains inline functions? Unless we freeze development in these inline functions and corresponding structures, it might not be possible to claim ABI compatibility. Application has to be recompiled.
2) Every function that is not in the direct datapath (fastpath?) should not be inline. Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free - Stephen
3) Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). - Konstantin
2) and 3) can be good guidelines to what functions/APIs can be inline. But, I believe this guideline exists today too. Are there any thoughts to change this?
Coming to 1), I think DPDK cannot provide ABI compatibility unless all the inline functions are converted to normal functions and symbol versioning is done for those (not bothering about performance).
In this context, does it make sense to say that we will maintain API compatibility rather than saying ABI compatibility? This will also send the right message to the end users.
Thank you,
Honnappa
[1] http://mails.dpdk.org/archives/dev/2019-April/130151.html
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-17 1:45 0% ` Honnappa Nagarahalli
@ 2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 1:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > >
> > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > slower, but you thank me
> > > > > the first time you have to fix something.
> > > > > > > > > > >
> > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > this (I am yet
> > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > to consider the performance
> > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > all the
> > > > > inline functions in its path and run a test?
> > > > > > > > >
> > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > not be
> > > > > inline.
> > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > have
> > > inline functions (unless we freeze any development in these inline
> > > functions forever).
> > > >
> > > > > > > >
> > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > more
> > > sophisticated).
> > > > > > > > Konstantin
> > > > > > >
> > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > rcu_reference/rcu_assign_pointer.
> > > > > > >
> > > > > > > The synchronization logic is all real functions.
> > > > > >
> > > > > > In fact, I think urcu provides both flavors:
> > > > > > https://github.com/urcu/userspace-
> > > > > rcu/blob/master/include/urcu/static/
> > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > probably want it to be as fast as possible (I know that main
> > > > > > speedup should come from the fact that readers don't have to
> > > > > > wait for writer to finish, but still...)
> > > > > >
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Having locking functions inline is already a problem in current
> releases.
> > > > > The implementation can not be improved without breaking ABI (or
> > > > > doing special workarounds like lock v2)
> > > > I think ABI and inline function discussion needs to be taken up in
> > > > a
> > > different thread.
> > > >
> > > > Currently, I am looking to hide the structure visibility. I looked
> > > > at your
> > > patch [1], it is a different case than what I have in this patch. It
> > > is a pretty generic use case as well (similar situation exists in
> > > other libraries). I think a generic solution should be agreed upon.
> > > >
> > > > If we have to hide the structure content, the handle to QS
> > > > variable
> > > returned to the application needs to be opaque. I suggest using 'void *'
> > > behind which any structure can be used.
> > > >
> > > > typedef void * rte_rcu_qsbr_t;
> > > > typedef void * rte_hash_t;
> > > >
> > > > But it requires typecasting.
> > > >
> > > > [1] http://patchwork.dpdk.org/cover/52609/
> > >
> > > C allows structure to be defined without knowing what is in it
> therefore.
> > >
> > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > >
> > > is preferred (or do it without typedef)
> > >
> > > struct rte_rcu_qsbr;
> >
> > I see that rte_hash library uses the same approach (struct rte_hash in
> rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> [1] seems to be reporting incorrect numbers for this library even though
> the internal structure is changed.
> >
> > [1]
> > https://abi-
> laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > 2&v2=current&obj=66794&kind=abi
>
> The problem is rte_hash structure is exposed as part of ABI in
> rte_cuckoo_hash.h This was a mistake.
Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to include rte_cuckoo_hash.h.
For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure while having inline functions.
I converted the inline functions to function calls.
Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
Konstantin, any thoughts on the results?
I will send out V6 which will fix issues reported so far. The function vs inline part is still open, need to close it soon.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
@ 2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-17 1:45 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > > > > >
> > > > > > > > > > > After evaluating long term API/ABI issues, I think
> > > > > > > > > > > you need to get rid of almost all use of inline and
> > > > > > > > > > > visible structures. Yes it might be marginally
> > > > > > > > > > > slower, but you thank me
> > > > > the first time you have to fix something.
> > > > > > > > > > >
> > > > > > > > > > Agree, I was planning on another version to address
> > > > > > > > > > this (I am yet
> > > > > to take a look at your patch addressing the ABI).
> > > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > > For the inline functions, is the plan to convert all
> > > > > > > > > > the inline functions in DPDK? If yes, I think we need
> > > > > > > > > > to consider the performance
> > > > > > > > > difference. May be consider L3-fwd application, change
> > > > > > > > > all the
> > > > > inline functions in its path and run a test?
> > > > > > > > >
> > > > > > > > > Every function that is not in the direct datapath should
> > > > > > > > > not be
> > > > > inline.
> > > > > > > > > Exceptions or things like rx/tx burst, ring
> > > > > > > > > enqueue/dequeue, and packet alloc/free
> > > > I do not understand how DPDK can claim ABI compatibility if we
> > > > have
> > > inline functions (unless we freeze any development in these inline
> > > functions forever).
> > > >
> > > > > > > >
> > > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > > another synchronization mechanism after all (just a bit
> > > > > > > > more
> > > sophisticated).
> > > > > > > > Konstantin
> > > > > > >
> > > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > > rcu_reference/rcu_assign_pointer.
> > > > > > >
> > > > > > > The synchronization logic is all real functions.
> > > > > >
> > > > > > In fact, I think urcu provides both flavors:
> > > > > > https://github.com/urcu/userspace-
> > > > > rcu/blob/master/include/urcu/static/
> > > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > > If we gone all the way to create our own version of rcu, we
> > > > > > probably want it to be as fast as possible (I know that main
> > > > > > speedup should come from the fact that readers don't have to
> > > > > > wait for writer to finish, but still...)
> > > > > >
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > Having locking functions inline is already a problem in current
> releases.
> > > > > The implementation can not be improved without breaking ABI (or
> > > > > doing special workarounds like lock v2)
> > > > I think ABI and inline function discussion needs to be taken up in
> > > > a
> > > different thread.
> > > >
> > > > Currently, I am looking to hide the structure visibility. I looked
> > > > at your
> > > patch [1], it is a different case than what I have in this patch. It
> > > is a pretty generic use case as well (similar situation exists in
> > > other libraries). I think a generic solution should be agreed upon.
> > > >
> > > > If we have to hide the structure content, the handle to QS
> > > > variable
> > > returned to the application needs to be opaque. I suggest using 'void *'
> > > behind which any structure can be used.
> > > >
> > > > typedef void * rte_rcu_qsbr_t;
> > > > typedef void * rte_hash_t;
> > > >
> > > > But it requires typecasting.
> > > >
> > > > [1] http://patchwork.dpdk.org/cover/52609/
> > >
> > > C allows structure to be defined without knowing what is in it
> therefore.
> > >
> > > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> > >
> > > is preferred (or do it without typedef)
> > >
> > > struct rte_rcu_qsbr;
> >
> > I see that rte_hash library uses the same approach (struct rte_hash in
> rte_hash.h, though it is marking as internal). But the ABI Laboratory tool
> [1] seems to be reporting incorrect numbers for this library even though
> the internal structure is changed.
> >
> > [1]
> > https://abi-
> laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.0
> > 2&v2=current&obj=66794&kind=abi
>
> The problem is rte_hash structure is exposed as part of ABI in
> rte_cuckoo_hash.h This was a mistake.
Do you mean, due to the use of structure with the same name? I am wondering if it is just a tools issue. The application is not supposed to include rte_cuckoo_hash.h.
For the RCU library, we either need to go all functions or leave it the way it is. I do not see a point in trying to hide the internal structure while having inline functions.
I converted the inline functions to function calls.
Testing on Arm platform (results *are* repeatable) shows very minimal drop (0.1% to 0.2%) in performance while using lock-free rte_hash data structure. But one of the test cases which is just spinning shows good amount of drop (41%).
Testing on x86 (Xeon Gold 6132 CPU @ 2.60GHz, results *are* pretty repeatable) shows performance improvements (7% to 8%) while using lock-free rte_hash data structure. The test cases which is just spinning show significant drop (14%, 155%, 231%).
Konstantin, any thoughts on the results?
I will send out V6 which will fix issues reported so far. The function vs inline part is still open, need to close it soon.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 21:22 3% ` Stephen Hemminger
@ 2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 21:22 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 16:56:32 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > > memory reclamation
> > > > > > > > > > method.
> > > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > > >
> > > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > > thank me
> > > > the first time you have to fix something.
> > > > > > > > > >
> > > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > > (I am yet
> > > > to take a look at your patch addressing the ABI).
> > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > > consider the performance
> > > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > > the
> > > > inline functions in its path and run a test?
> > > > > > > >
> > > > > > > > Every function that is not in the direct datapath should not
> > > > > > > > be
> > > > inline.
> > > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > > and packet alloc/free
> > > I do not understand how DPDK can claim ABI compatibility if we have
> > inline functions (unless we freeze any development in these inline functions
> > forever).
> > >
> > > > > > >
> > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > another synchronization mechanism after all (just a bit more
> > sophisticated).
> > > > > > > Konstantin
> > > > > >
> > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > rcu_reference/rcu_assign_pointer.
> > > > > >
> > > > > > The synchronization logic is all real functions.
> > > > >
> > > > > In fact, I think urcu provides both flavors:
> > > > > https://github.com/urcu/userspace-
> > > > rcu/blob/master/include/urcu/static/
> > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > If we gone all the way to create our own version of rcu, we
> > > > > probably want it to be as fast as possible (I know that main
> > > > > speedup should come from the fact that readers don't have to wait
> > > > > for writer to finish, but still...)
> > > > >
> > > > > Konstantin
> > > > >
> > > >
> > > > Having locking functions inline is already a problem in current releases.
> > > > The implementation can not be improved without breaking ABI (or
> > > > doing special workarounds like lock v2)
> > > I think ABI and inline function discussion needs to be taken up in a
> > different thread.
> > >
> > > Currently, I am looking to hide the structure visibility. I looked at your
> > patch [1], it is a different case than what I have in this patch. It is a pretty
> > generic use case as well (similar situation exists in other libraries). I think a
> > generic solution should be agreed upon.
> > >
> > > If we have to hide the structure content, the handle to QS variable
> > returned to the application needs to be opaque. I suggest using 'void *'
> > behind which any structure can be used.
> > >
> > > typedef void * rte_rcu_qsbr_t;
> > > typedef void * rte_hash_t;
> > >
> > > But it requires typecasting.
> > >
> > > [1] http://patchwork.dpdk.org/cover/52609/
> >
> > C allows structure to be defined without knowing what is in it therefore.
> >
> > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> >
> > is preferred (or do it without typedef)
> >
> > struct rte_rcu_qsbr;
>
> I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
>
> [1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
The problem is rte_hash structure is exposed as part of ABI in rte_cuckoo_hash.h
This was a mistake.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
@ 2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 21:22 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 16:56:32 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > > memory reclamation
> > > > > > > > > > method.
> > > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > > >
> > > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > > thank me
> > > > the first time you have to fix something.
> > > > > > > > > >
> > > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > > (I am yet
> > > > to take a look at your patch addressing the ABI).
> > > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > > consider the performance
> > > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > > the
> > > > inline functions in its path and run a test?
> > > > > > > >
> > > > > > > > Every function that is not in the direct datapath should not
> > > > > > > > be
> > > > inline.
> > > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > > and packet alloc/free
> > > I do not understand how DPDK can claim ABI compatibility if we have
> > inline functions (unless we freeze any development in these inline functions
> > forever).
> > >
> > > > > > >
> > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > > another synchronization mechanism after all (just a bit more
> > sophisticated).
> > > > > > > Konstantin
> > > > > >
> > > > > > If you look at the other userspace RCU, you wil see that the
> > > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > > rcu_reference/rcu_assign_pointer.
> > > > > >
> > > > > > The synchronization logic is all real functions.
> > > > >
> > > > > In fact, I think urcu provides both flavors:
> > > > > https://github.com/urcu/userspace-
> > > > rcu/blob/master/include/urcu/static/
> > > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > > If we gone all the way to create our own version of rcu, we
> > > > > probably want it to be as fast as possible (I know that main
> > > > > speedup should come from the fact that readers don't have to wait
> > > > > for writer to finish, but still...)
> > > > >
> > > > > Konstantin
> > > > >
> > > >
> > > > Having locking functions inline is already a problem in current releases.
> > > > The implementation can not be improved without breaking ABI (or
> > > > doing special workarounds like lock v2)
> > > I think ABI and inline function discussion needs to be taken up in a
> > different thread.
> > >
> > > Currently, I am looking to hide the structure visibility. I looked at your
> > patch [1], it is a different case than what I have in this patch. It is a pretty
> > generic use case as well (similar situation exists in other libraries). I think a
> > generic solution should be agreed upon.
> > >
> > > If we have to hide the structure content, the handle to QS variable
> > returned to the application needs to be opaque. I suggest using 'void *'
> > behind which any structure can be used.
> > >
> > > typedef void * rte_rcu_qsbr_t;
> > > typedef void * rte_hash_t;
> > >
> > > But it requires typecasting.
> > >
> > > [1] http://patchwork.dpdk.org/cover/52609/
> >
> > C allows structure to be defined without knowing what is in it therefore.
> >
> > typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
> >
> > is preferred (or do it without typedef)
> >
> > struct rte_rcu_qsbr;
>
> I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
>
> [1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
The problem is rte_hash structure is exposed as part of ABI in rte_cuckoo_hash.h
This was a mistake.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 16:56 4% ` Honnappa Nagarahalli
@ 2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
>
> > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > >
> > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > memory reclamation
> > > > > > > > > method.
> > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > >
> > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > thank me
> > > the first time you have to fix something.
> > > > > > > > >
> > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > (I am yet
> > > to take a look at your patch addressing the ABI).
> > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > consider the performance
> > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > the
> > > inline functions in its path and run a test?
> > > > > > >
> > > > > > > Every function that is not in the direct datapath should not
> > > > > > > be
> > > inline.
> > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > and packet alloc/free
> > I do not understand how DPDK can claim ABI compatibility if we have
> inline functions (unless we freeze any development in these inline functions
> forever).
> >
> > > > > >
> > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > another synchronization mechanism after all (just a bit more
> sophisticated).
> > > > > > Konstantin
> > > > >
> > > > > If you look at the other userspace RCU, you wil see that the
> > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > rcu_reference/rcu_assign_pointer.
> > > > >
> > > > > The synchronization logic is all real functions.
> > > >
> > > > In fact, I think urcu provides both flavors:
> > > > https://github.com/urcu/userspace-
> > > rcu/blob/master/include/urcu/static/
> > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > If we gone all the way to create our own version of rcu, we
> > > > probably want it to be as fast as possible (I know that main
> > > > speedup should come from the fact that readers don't have to wait
> > > > for writer to finish, but still...)
> > > >
> > > > Konstantin
> > > >
> > >
> > > Having locking functions inline is already a problem in current releases.
> > > The implementation can not be improved without breaking ABI (or
> > > doing special workarounds like lock v2)
> > I think ABI and inline function discussion needs to be taken up in a
> different thread.
> >
> > Currently, I am looking to hide the structure visibility. I looked at your
> patch [1], it is a different case than what I have in this patch. It is a pretty
> generic use case as well (similar situation exists in other libraries). I think a
> generic solution should be agreed upon.
> >
> > If we have to hide the structure content, the handle to QS variable
> returned to the application needs to be opaque. I suggest using 'void *'
> behind which any structure can be used.
> >
> > typedef void * rte_rcu_qsbr_t;
> > typedef void * rte_hash_t;
> >
> > But it requires typecasting.
> >
> > [1] http://patchwork.dpdk.org/cover/52609/
>
> C allows structure to be defined without knowing what is in it therefore.
>
> typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
>
> is preferred (or do it without typedef)
>
> struct rte_rcu_qsbr;
I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
[1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
@ 2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd, nd
>
> > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > > >
> > > > > > > > > > Add RCU library supporting quiescent state based
> > > > > > > > > > memory reclamation
> > > > > > > > > method.
> > > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > > associated with the lock less data structures.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > > >
> > > > > > > > > After evaluating long term API/ABI issues, I think you
> > > > > > > > > need to get rid of almost all use of inline and visible
> > > > > > > > > structures. Yes it might be marginally slower, but you
> > > > > > > > > thank me
> > > the first time you have to fix something.
> > > > > > > > >
> > > > > > > > Agree, I was planning on another version to address this
> > > > > > > > (I am yet
> > > to take a look at your patch addressing the ABI).
> > > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > > inline functions in DPDK? If yes, I think we need to
> > > > > > > > consider the performance
> > > > > > > difference. May be consider L3-fwd application, change all
> > > > > > > the
> > > inline functions in its path and run a test?
> > > > > > >
> > > > > > > Every function that is not in the direct datapath should not
> > > > > > > be
> > > inline.
> > > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue,
> > > > > > > and packet alloc/free
> > I do not understand how DPDK can claim ABI compatibility if we have
> inline functions (unless we freeze any development in these inline functions
> forever).
> >
> > > > > >
> > > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > > I think rcu should be one of such exceptions - it is just
> > > > > > another synchronization mechanism after all (just a bit more
> sophisticated).
> > > > > > Konstantin
> > > > >
> > > > > If you look at the other userspace RCU, you wil see that the
> > > > > only inlines are the rcu_read_lock,rcu_read_unlock and
> > > rcu_reference/rcu_assign_pointer.
> > > > >
> > > > > The synchronization logic is all real functions.
> > > >
> > > > In fact, I think urcu provides both flavors:
> > > > https://github.com/urcu/userspace-
> > > rcu/blob/master/include/urcu/static/
> > > > urcu-qsbr.h I still don't understand why we have to treat it
> > > > differently then let say spin-lock/ticket-lock or rwlock.
> > > > If we gone all the way to create our own version of rcu, we
> > > > probably want it to be as fast as possible (I know that main
> > > > speedup should come from the fact that readers don't have to wait
> > > > for writer to finish, but still...)
> > > >
> > > > Konstantin
> > > >
> > >
> > > Having locking functions inline is already a problem in current releases.
> > > The implementation can not be improved without breaking ABI (or
> > > doing special workarounds like lock v2)
> > I think ABI and inline function discussion needs to be taken up in a
> different thread.
> >
> > Currently, I am looking to hide the structure visibility. I looked at your
> patch [1], it is a different case than what I have in this patch. It is a pretty
> generic use case as well (similar situation exists in other libraries). I think a
> generic solution should be agreed upon.
> >
> > If we have to hide the structure content, the handle to QS variable
> returned to the application needs to be opaque. I suggest using 'void *'
> behind which any structure can be used.
> >
> > typedef void * rte_rcu_qsbr_t;
> > typedef void * rte_hash_t;
> >
> > But it requires typecasting.
> >
> > [1] http://patchwork.dpdk.org/cover/52609/
>
> C allows structure to be defined without knowing what is in it therefore.
>
> typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
>
> is preferred (or do it without typedef)
>
> struct rte_rcu_qsbr;
I see that rte_hash library uses the same approach (struct rte_hash in rte_hash.h, though it is marking as internal). But the ABI Laboratory tool [1] seems to be reporting incorrect numbers for this library even though the internal structure is changed.
[1] https://abi-laboratory.pro/index.php?view=compat_report&l=dpdk&v1=19.02&v2=current&obj=66794&kind=abi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 14:54 0% ` Stephen Hemminger
@ 2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 14:54 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 05:29:21 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > >
> > > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > > reclamation
> > > > > > > > method.
> > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > associated with the lock less data structures.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > >
> > > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > > to get rid of almost all use of inline and visible
> > > > > > > > structures. Yes it might be marginally slower, but you thank me
> > the first time you have to fix something.
> > > > > > > >
> > > > > > > Agree, I was planning on another version to address this (I am yet
> > to take a look at your patch addressing the ABI).
> > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > > the performance
> > > > > > difference. May be consider L3-fwd application, change all the
> > inline functions in its path and run a test?
> > > > > >
> > > > > > Every function that is not in the direct datapath should not be
> > inline.
> > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > > packet alloc/free
> I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
>
> > > > >
> > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > I think rcu should be one of such exceptions - it is just another
> > > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > > Konstantin
> > > >
> > > > If you look at the other userspace RCU, you wil see that the only
> > > > inlines are the rcu_read_lock,rcu_read_unlock and
> > rcu_reference/rcu_assign_pointer.
> > > >
> > > > The synchronization logic is all real functions.
> > >
> > > In fact, I think urcu provides both flavors:
> > > https://github.com/urcu/userspace-
> > rcu/blob/master/include/urcu/static/
> > > urcu-qsbr.h I still don't understand why we have to treat it
> > > differently then let say spin-lock/ticket-lock or rwlock.
> > > If we gone all the way to create our own version of rcu, we probably
> > > want it to be as fast as possible (I know that main speedup should
> > > come from the fact that readers don't have to wait for writer to
> > > finish, but still...)
> > >
> > > Konstantin
> > >
> >
> > Having locking functions inline is already a problem in current releases.
> > The implementation can not be improved without breaking ABI (or doing
> > special workarounds like lock v2)
> I think ABI and inline function discussion needs to be taken up in a different thread.
>
> Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
>
> If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
>
> typedef void * rte_rcu_qsbr_t;
> typedef void * rte_hash_t;
>
> But it requires typecasting.
>
> [1] http://patchwork.dpdk.org/cover/52609/
C allows structure to be defined without knowing what is in it
therefore.
typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
is preferred (or do it without typedef)
struct rte_rcu_qsbr;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
@ 2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-16 14:54 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: Ananyev, Konstantin, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Tue, 16 Apr 2019 05:29:21 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > > >
> > > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > > reclamation
> > > > > > > > method.
> > > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > > associated with the lock less data structures.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > > >
> > > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > > to get rid of almost all use of inline and visible
> > > > > > > > structures. Yes it might be marginally slower, but you thank me
> > the first time you have to fix something.
> > > > > > > >
> > > > > > > Agree, I was planning on another version to address this (I am yet
> > to take a look at your patch addressing the ABI).
> > > > > > > The structure visibility definitely needs to be addressed.
> > > > > > > For the inline functions, is the plan to convert all the
> > > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > > the performance
> > > > > > difference. May be consider L3-fwd application, change all the
> > inline functions in its path and run a test?
> > > > > >
> > > > > > Every function that is not in the direct datapath should not be
> > inline.
> > > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > > packet alloc/free
> I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
>
> > > > >
> > > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > > I think rcu should be one of such exceptions - it is just another
> > > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > > Konstantin
> > > >
> > > > If you look at the other userspace RCU, you wil see that the only
> > > > inlines are the rcu_read_lock,rcu_read_unlock and
> > rcu_reference/rcu_assign_pointer.
> > > >
> > > > The synchronization logic is all real functions.
> > >
> > > In fact, I think urcu provides both flavors:
> > > https://github.com/urcu/userspace-
> > rcu/blob/master/include/urcu/static/
> > > urcu-qsbr.h I still don't understand why we have to treat it
> > > differently then let say spin-lock/ticket-lock or rwlock.
> > > If we gone all the way to create our own version of rcu, we probably
> > > want it to be as fast as possible (I know that main speedup should
> > > come from the fact that readers don't have to wait for writer to
> > > finish, but still...)
> > >
> > > Konstantin
> > >
> >
> > Having locking functions inline is already a problem in current releases.
> > The implementation can not be improved without breaking ABI (or doing
> > special workarounds like lock v2)
> I think ABI and inline function discussion needs to be taken up in a different thread.
>
> Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
>
> If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
>
> typedef void * rte_rcu_qsbr_t;
> typedef void * rte_hash_t;
>
> But it requires typecasting.
>
> [1] http://patchwork.dpdk.org/cover/52609/
C allows structure to be defined without knowing what is in it
therefore.
typedef struct rte_rcu_qsbr rte_rcu_qsbr_t;
is preferred (or do it without typedef)
struct rte_rcu_qsbr;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:19 0% ` Igor Russkikh
@ 2019-04-16 10:19 0% ` Igor Russkikh
0 siblings, 0 replies; 200+ results
From: Igor Russkikh @ 2019-04-16 10:19 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko
Cc: Ferruh Yigit, dev, Pavel Belous, Wenzhuo Lu, Jingjing Wu,
Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
>>>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>>>> other possible driver can use it, I am for postponing the series to next release.
>>>>>
>>>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>>>> to late in release cycle without proper review.
>>>> I see, that's reasonable.
>>>>
>>>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>>>> Two points here:
>>>>
>>>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>>>> through the rte_security set of APIs. This obviously could be done, but with proper design
>>>> of rte_security structures and ops.
>>>>
>>>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>>>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>>>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>>>
>>> If there is a commitment to work on a generic solution for 19.08, involving
>>> other users too, I would be OK to get the support as PMD API for this release.
>>>
>>> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
>>> even add to release notes about intention and that the PMD specific APIs are
>>> temporary. And if ABI breakage required, put any necessary deprecation notice
>>> withing this release scope so that the development is not blocked for next release.
>>>
>>> Thomas, Andrew, what do you think?
>>
>> I agree.
>
> +1
Great, I'll prepare v2 patchset then. Will also start on prototyping possible
rte_security macsec API.
Regards,
Igor
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
@ 2019-04-16 10:19 0% ` Igor Russkikh
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 1 reply; 200+ results
From: Igor Russkikh @ 2019-04-16 10:19 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko
Cc: Ferruh Yigit, dev, Pavel Belous, Wenzhuo Lu, Jingjing Wu,
Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
>>>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>>>> other possible driver can use it, I am for postponing the series to next release.
>>>>>
>>>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>>>> to late in release cycle without proper review.
>>>> I see, that's reasonable.
>>>>
>>>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>>>> Two points here:
>>>>
>>>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>>>> through the rte_security set of APIs. This obviously could be done, but with proper design
>>>> of rte_security structures and ops.
>>>>
>>>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>>>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>>>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>>>
>>> If there is a commitment to work on a generic solution for 19.08, involving
>>> other users too, I would be OK to get the support as PMD API for this release.
>>>
>>> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
>>> even add to release notes about intention and that the PMD specific APIs are
>>> temporary. And if ABI breakage required, put any necessary deprecation notice
>>> withing this release scope so that the development is not blocked for next release.
>>>
>>> Thomas, Andrew, what do you think?
>>
>> I agree.
>
> +1
Great, I'll prepare v2 patchset then. Will also start on prototyping possible
rte_security macsec API.
Regards,
Igor
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 10:11 0% ` Thomas Monjalon
@ 2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-16 10:11 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Igor Russkikh, dev, Pavel Belous, Wenzhuo Lu,
Jingjing Wu, Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
16/04/2019 11:58, Andrew Rybchenko:
> On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> > On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> >> Hi Ferruh,
> >>
> >>>> +int
> >>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
> >>>> + uint8_t idx, uint8_t an,
> >>>> + uint32_t pn, uint8_t *key);
> >>>> +
> >>>>
> >>>> #include <rte_ethdev_core.h>
> >>>>
> >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
> >>> these didn't go through a proper review cycle, we didn't get any comment on any
> >>> other possible driver can use it, I am for postponing the series to next release.
> >>>
> >>> Also there are some mechanical issues [1] but main thing is adding a set of API
> >>> to late in release cycle without proper review.
> >> I see, that's reasonable.
> >>
> >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> >> Two points here:
> >>
> >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> >> through the rte_security set of APIs. This obviously could be done, but with proper design
> >> of rte_security structures and ops.
> >>
> >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> >> of private driver API as it runs in ixgbe now. This code is functional and will not be
> >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
> >>
> > If there is a commitment to work on a generic solution for 19.08, involving
> > other users too, I would be OK to get the support as PMD API for this release.
> >
> > If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> > even add to release notes about intention and that the PMD specific APIs are
> > temporary. And if ABI breakage required, put any necessary deprecation notice
> > withing this release scope so that the development is not blocked for next release.
> >
> > Thomas, Andrew, what do you think?
>
> I agree.
+1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
@ 2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-16 10:11 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Ferruh Yigit, Igor Russkikh, dev, Pavel Belous, Wenzhuo Lu,
Jingjing Wu, Bernard Iremonger, John McNamara, Marko Kovacevic,
Konstantin Ananyev
16/04/2019 11:58, Andrew Rybchenko:
> On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> > On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> >> Hi Ferruh,
> >>
> >>>> +int
> >>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
> >>>> + uint8_t idx, uint8_t an,
> >>>> + uint32_t pn, uint8_t *key);
> >>>> +
> >>>>
> >>>> #include <rte_ethdev_core.h>
> >>>>
> >>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
> >>> these didn't go through a proper review cycle, we didn't get any comment on any
> >>> other possible driver can use it, I am for postponing the series to next release.
> >>>
> >>> Also there are some mechanical issues [1] but main thing is adding a set of API
> >>> to late in release cycle without proper review.
> >> I see, that's reasonable.
> >>
> >> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> >> Two points here:
> >>
> >> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> >> through the rte_security set of APIs. This obviously could be done, but with proper design
> >> of rte_security structures and ops.
> >>
> >> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> >> of private driver API as it runs in ixgbe now. This code is functional and will not be
> >> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
> >>
> > If there is a commitment to work on a generic solution for 19.08, involving
> > other users too, I would be OK to get the support as PMD API for this release.
> >
> > If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> > even add to release notes about intention and that the PMD specific APIs are
> > temporary. And if ABI breakage required, put any necessary deprecation notice
> > withing this release scope so that the development is not blocked for next release.
> >
> > Thomas, Andrew, what do you think?
>
> I agree.
+1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:58 0% ` Andrew Rybchenko
@ 2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-04-16 9:58 UTC (permalink / raw)
To: Ferruh Yigit, Igor Russkikh, dev, Thomas Monjalon
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> On 4/13/2019 8:24 AM, Igor Russkikh wrote:
>> Hi Ferruh,
>>
>>>> +int
>>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>>> + uint8_t idx, uint8_t an,
>>>> + uint32_t pn, uint8_t *key);
>>>> +
>>>>
>>>> #include <rte_ethdev_core.h>
>>>>
>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>> other possible driver can use it, I am for postponing the series to next release.
>>>
>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>> to late in release cycle without proper review.
>> I see, that's reasonable.
>>
>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>> Two points here:
>>
>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>> through the rte_security set of APIs. This obviously could be done, but with proper design
>> of rte_security structures and ops.
>>
>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>
> If there is a commitment to work on a generic solution for 19.08, involving
> other users too, I would be OK to get the support as PMD API for this release.
>
> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> even add to release notes about intention and that the PMD specific APIs are
> temporary. And if ABI breakage required, put any necessary deprecation notice
> withing this release scope so that the development is not blocked for next release.
>
> Thomas, Andrew, what do you think?
I agree.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
@ 2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Andrew Rybchenko @ 2019-04-16 9:58 UTC (permalink / raw)
To: Ferruh Yigit, Igor Russkikh, dev, Thomas Monjalon
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/16/19 12:43 PM, Ferruh Yigit wrote:
> On 4/13/2019 8:24 AM, Igor Russkikh wrote:
>> Hi Ferruh,
>>
>>>> +int
>>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>>> + uint8_t idx, uint8_t an,
>>>> + uint32_t pn, uint8_t *key);
>>>> +
>>>>
>>>> #include <rte_ethdev_core.h>
>>>>
>>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>>> these didn't go through a proper review cycle, we didn't get any comment on any
>>> other possible driver can use it, I am for postponing the series to next release.
>>>
>>> Also there are some mechanical issues [1] but main thing is adding a set of API
>>> to late in release cycle without proper review.
>> I see, that's reasonable.
>>
>> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
>> Two points here:
>>
>> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
>> through the rte_security set of APIs. This obviously could be done, but with proper design
>> of rte_security structures and ops.
>>
>> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
>> of private driver API as it runs in ixgbe now. This code is functional and will not be
>> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>>
> If there is a commitment to work on a generic solution for 19.08, involving
> other users too, I would be OK to get the support as PMD API for this release.
>
> If that is accepted, please bu sure too add experimental tag to new PMD APIs and
> even add to release notes about intention and that the PMD specific APIs are
> temporary. And if ABI breakage required, put any necessary deprecation notice
> withing this release scope so that the development is not blocked for next release.
>
> Thomas, Andrew, what do you think?
I agree.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
2019-04-16 9:43 3% ` Ferruh Yigit
@ 2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-16 9:43 UTC (permalink / raw)
To: Igor Russkikh, dev, Thomas Monjalon, Andrew Rybchenko
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> Hi Ferruh,
>
>>> +int
>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>> + uint8_t idx, uint8_t an,
>>> + uint32_t pn, uint8_t *key);
>>> +
>>>
>>> #include <rte_ethdev_core.h>
>>>
>>
>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>> these didn't go through a proper review cycle, we didn't get any comment on any
>> other possible driver can use it, I am for postponing the series to next release.
>>
>> Also there are some mechanical issues [1] but main thing is adding a set of API
>> to late in release cycle without proper review.
>
> I see, that's reasonable.
>
> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> Two points here:
>
> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> through the rte_security set of APIs. This obviously could be done, but with proper design
> of rte_security structures and ops.
>
> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> of private driver API as it runs in ixgbe now. This code is functional and will not be
> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>
If there is a commitment to work on a generic solution for 19.08, involving
other users too, I would be OK to get the support as PMD API for this release.
If that is accepted, please bu sure too add experimental tag to new PMD APIs and
even add to release notes about intention and that the PMD specific APIs are
temporary. And if ABI breakage required, put any necessary deprecation notice
withing this release scope so that the development is not blocked for next release.
Thomas, Andrew, what do you think?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops
@ 2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-16 9:43 UTC (permalink / raw)
To: Igor Russkikh, dev, Thomas Monjalon, Andrew Rybchenko
Cc: Pavel Belous, Wenzhuo Lu, Jingjing Wu, Bernard Iremonger,
John McNamara, Marko Kovacevic, Konstantin Ananyev
On 4/13/2019 8:24 AM, Igor Russkikh wrote:
> Hi Ferruh,
>
>>> +int
>>> +rte_eth_macsec_select_txsa(uint16_t port_id,
>>> + uint8_t idx, uint8_t an,
>>> + uint32_t pn, uint8_t *key);
>>> +
>>>
>>> #include <rte_ethdev_core.h>
>>>
>>
>> These are new ethdev APIs, not driver code, that have been sent after rc1, so
>> these didn't go through a proper review cycle, we didn't get any comment on any
>> other possible driver can use it, I am for postponing the series to next release.
>>
>> Also there are some mechanical issues [1] but main thing is adding a set of API
>> to late in release cycle without proper review.
>
> I see, that's reasonable.
>
> May I suggest another option then: can we do driver only API (almost like ixgbe providing now)?
> Two points here:
>
> 1) Thomas raised a reasonable question whether all the macsec control in general should happen
> through the rte_security set of APIs. This obviously could be done, but with proper design
> of rte_security structures and ops.
>
> 2) Aquantia is interested in having macsec control code in driver within 19.05, even in form
> of private driver API as it runs in ixgbe now. This code is functional and will not be
> changed alot anyway. It could be easily adopted later when point (1) gets a conclusion.
>
If there is a commitment to work on a generic solution for 19.08, involving
other users too, I would be OK to get the support as PMD API for this release.
If that is accepted, please bu sure too add experimental tag to new PMD APIs and
even add to release notes about intention and that the PMD specific APIs are
temporary. And if ABI breakage required, put any necessary deprecation notice
withing this release scope so that the development is not blocked for next release.
Thomas, Andrew, what do you think?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-16 5:29 4% ` Honnappa Nagarahalli
@ 2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 5:29 UTC (permalink / raw)
To: Stephen Hemminger, Ananyev, Konstantin
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > >
> > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > reclamation
> > > > > > > method.
> > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > associated with the lock less data structures.
> > > > > > > >
> > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > to get rid of almost all use of inline and visible
> > > > > > > structures. Yes it might be marginally slower, but you thank me
> the first time you have to fix something.
> > > > > > >
> > > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > > The structure visibility definitely needs to be addressed.
> > > > > > For the inline functions, is the plan to convert all the
> > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > the performance
> > > > > difference. May be consider L3-fwd application, change all the
> inline functions in its path and run a test?
> > > > >
> > > > > Every function that is not in the direct datapath should not be
> inline.
> > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > packet alloc/free
I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
> > > >
> > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > I think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > Konstantin
> > >
> > > If you look at the other userspace RCU, you wil see that the only
> > > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> > >
> > > The synchronization logic is all real functions.
> >
> > In fact, I think urcu provides both flavors:
> > https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/
> > urcu-qsbr.h I still don't understand why we have to treat it
> > differently then let say spin-lock/ticket-lock or rwlock.
> > If we gone all the way to create our own version of rcu, we probably
> > want it to be as fast as possible (I know that main speedup should
> > come from the fact that readers don't have to wait for writer to
> > finish, but still...)
> >
> > Konstantin
> >
>
> Having locking functions inline is already a problem in current releases.
> The implementation can not be improved without breaking ABI (or doing
> special workarounds like lock v2)
I think ABI and inline function discussion needs to be taken up in a different thread.
Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
typedef void * rte_rcu_qsbr_t;
typedef void * rte_hash_t;
But it requires typecasting.
[1] http://patchwork.dpdk.org/cover/52609/
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
@ 2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-16 5:29 UTC (permalink / raw)
To: Stephen Hemminger, Ananyev, Konstantin
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 Honnappa Nagarahalli
> > > > > > > <honnappa.nagarahalli@arm.com> wrote:
> > > > > > >
> > > > > > > > Add RCU library supporting quiescent state based memory
> > > > > > > > reclamation
> > > > > > > method.
> > > > > > > > This library helps identify the quiescent state of the
> > > > > > > > reader threads so that the writers can free the memory
> > > > > > > > associated with the lock less data structures.
> > > > > > > >
> > > > > > > > Signed-off-by: Honnappa Nagarahalli
> > > > > > > > <honnappa.nagarahalli@arm.com>
> > > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > > Acked-by: Konstantin Ananyev
> > > > > > > > <konstantin.ananyev@intel.com>
> > > > > > >
> > > > > > > After evaluating long term API/ABI issues, I think you need
> > > > > > > to get rid of almost all use of inline and visible
> > > > > > > structures. Yes it might be marginally slower, but you thank me
> the first time you have to fix something.
> > > > > > >
> > > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > > The structure visibility definitely needs to be addressed.
> > > > > > For the inline functions, is the plan to convert all the
> > > > > > inline functions in DPDK? If yes, I think we need to consider
> > > > > > the performance
> > > > > difference. May be consider L3-fwd application, change all the
> inline functions in its path and run a test?
> > > > >
> > > > > Every function that is not in the direct datapath should not be
> inline.
> > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > > packet alloc/free
I do not understand how DPDK can claim ABI compatibility if we have inline functions (unless we freeze any development in these inline functions forever).
> > > >
> > > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > > I think rcu should be one of such exceptions - it is just another
> > > > synchronization mechanism after all (just a bit more sophisticated).
> > > > Konstantin
> > >
> > > If you look at the other userspace RCU, you wil see that the only
> > > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> > >
> > > The synchronization logic is all real functions.
> >
> > In fact, I think urcu provides both flavors:
> > https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/
> > urcu-qsbr.h I still don't understand why we have to treat it
> > differently then let say spin-lock/ticket-lock or rwlock.
> > If we gone all the way to create our own version of rcu, we probably
> > want it to be as fast as possible (I know that main speedup should
> > come from the fact that readers don't have to wait for writer to
> > finish, but still...)
> >
> > Konstantin
> >
>
> Having locking functions inline is already a problem in current releases.
> The implementation can not be improved without breaking ABI (or doing
> special workarounds like lock v2)
I think ABI and inline function discussion needs to be taken up in a different thread.
Currently, I am looking to hide the structure visibility. I looked at your patch [1], it is a different case than what I have in this patch. It is a pretty generic use case as well (similar situation exists in other libraries). I think a generic solution should be agreed upon.
If we have to hide the structure content, the handle to QS variable returned to the application needs to be opaque. I suggest using 'void *' behind which any structure can be used.
typedef void * rte_rcu_qsbr_t;
typedef void * rte_hash_t;
But it requires typecasting.
[1] http://patchwork.dpdk.org/cover/52609/
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-15 22:14 0% ` Thomas Monjalon
@ 2019-04-15 22:14 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-15 22:14 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable
05/04/2019 13:22, Neil Horman:
> On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> > Currently, when symbols get promoted from the EXPERIMENTAL section to a
> > stable ABI section, the script complains they should go to the
> > EXPERIMENTAL section.
> >
> > Example:
> > ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> > expected to be added in the EXPERIMENTAL section of the version map
> >
> > This is legit.
> > Moving from a stable ABI to another is also allowed, but must have gone
> > through the proper process.
> >
> > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
@ 2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-15 22:14 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable
05/04/2019 13:22, Neil Horman:
> On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> > Currently, when symbols get promoted from the EXPERIMENTAL section to a
> > stable ABI section, the script complains they should go to the
> > EXPERIMENTAL section.
> >
> > Example:
> > ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> > expected to be added in the EXPERIMENTAL section of the version map
> >
> > This is legit.
> > Moving from a stable ABI to another is also allowed, but must have gone
> > through the proper process.
> >
> > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 0/2] Timer library changes
2019-04-15 21:41 5% ` [dpdk-dev] [PATCH v5 " Erik Gabriel Carrillo
@ 2019-04-15 21:41 5% ` Erik Gabriel Carrillo
0 siblings, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-04-15 21:41 UTC (permalink / raw)
To: rsanford, thomas; +Cc: dev
This patch series modifies the timer library in such a way that
structures that used to be statically allocated in a process's data
segment are now allocated in shared memory. As these structures contain
lists of timers, new APIs are introduced that allow a caller to specify
the particular structure instance into which a timer should be inserted
or from which a timer should be removed. This enables primary and
secondary processes to modify the same timer list, which enables some
multi-process use cases that were not previously possible; e.g. a
secondary process can start a timer whose expiration is detected in a
primary process running a new flavor of timer_manage().
The original library API is mostly unchanged, though implementations are
updated to call into newly added functions with a default structure
instance ID that provides the original behavior. New functions are
introduced to enable applications to allocate structure instances to
house timer lists, and to reference them with an identifier when
starting and stopping timers, and finally, to manage the timer lists
referenced with an identifier.
My initial performance testing with the "timer_perf_autotest" test shows
no performance regression or improvement, and inspection of the
generated optimized code shows that the extra function call gets inlined
in the functions that now have an extra function call.
Changes in v5:
- define default_data_id as const (Robert)
- modify for-loop control in rte_timer_alt_manage and
rte_timer_stop_all (Robert)
- change parameter type in rte_timer_alt_manage_cb_t from "void *" to
"struct rte_timer *" (Robert)
Changes in v4:
- Updated versioned symbols so that they correspond to the next
release. Checked ABI compatibility again with validate-abi.sh.
Changes in v3:
- remove C++ style comment in first patch in series (Stephen)
Changes in v2:
- split these changes out into their own series
- version the symbols where the existing ABI was updated, and
provide alternate implementation with behavior equivalent to original
behavior. Validated ABI compatibility with validate-abi.sh
- refactor changes to simplify patches
Erik Gabriel Carrillo (2):
timer: allow timer management in shared memory
timer: add function to stop all timers in a list
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 557 ++++++++++++++++++++++++++++++---
lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
lib/librte_timer/rte_timer_version.map | 23 ++
4 files changed, 794 insertions(+), 45 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v5 0/2] Timer library changes
@ 2019-04-15 21:41 5% ` Erik Gabriel Carrillo
2019-04-15 21:41 5% ` Erik Gabriel Carrillo
0 siblings, 1 reply; 200+ results
From: Erik Gabriel Carrillo @ 2019-04-15 21:41 UTC (permalink / raw)
To: rsanford, thomas; +Cc: dev
This patch series modifies the timer library in such a way that
structures that used to be statically allocated in a process's data
segment are now allocated in shared memory. As these structures contain
lists of timers, new APIs are introduced that allow a caller to specify
the particular structure instance into which a timer should be inserted
or from which a timer should be removed. This enables primary and
secondary processes to modify the same timer list, which enables some
multi-process use cases that were not previously possible; e.g. a
secondary process can start a timer whose expiration is detected in a
primary process running a new flavor of timer_manage().
The original library API is mostly unchanged, though implementations are
updated to call into newly added functions with a default structure
instance ID that provides the original behavior. New functions are
introduced to enable applications to allocate structure instances to
house timer lists, and to reference them with an identifier when
starting and stopping timers, and finally, to manage the timer lists
referenced with an identifier.
My initial performance testing with the "timer_perf_autotest" test shows
no performance regression or improvement, and inspection of the
generated optimized code shows that the extra function call gets inlined
in the functions that now have an extra function call.
Changes in v5:
- define default_data_id as const (Robert)
- modify for-loop control in rte_timer_alt_manage and
rte_timer_stop_all (Robert)
- change parameter type in rte_timer_alt_manage_cb_t from "void *" to
"struct rte_timer *" (Robert)
Changes in v4:
- Updated versioned symbols so that they correspond to the next
release. Checked ABI compatibility again with validate-abi.sh.
Changes in v3:
- remove C++ style comment in first patch in series (Stephen)
Changes in v2:
- split these changes out into their own series
- version the symbols where the existing ABI was updated, and
provide alternate implementation with behavior equivalent to original
behavior. Validated ABI compatibility with validate-abi.sh
- refactor changes to simplify patches
Erik Gabriel Carrillo (2):
timer: allow timer management in shared memory
timer: add function to stop all timers in a list
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 557 ++++++++++++++++++++++++++++++---
lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
lib/librte_timer/rte_timer_version.map | 23 ++
4 files changed, 794 insertions(+), 45 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 21:26 3% ` Stephen Hemminger
@ 2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 21:26 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 17:39:07 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, April 15, 2019 4:39 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> > <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> > <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Mon, 15 Apr 2019 12:24:47 +0000
> > "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Saturday, April 13, 2019 12:06 AM
> > > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> > Gupta
> > > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > > >
> > > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > >
> > > > > >
> > > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > > >
> > > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > > method.
> > > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > > so that the writers can free the memory associated with the lock less
> > > > > > > data structures.
> > > > > > >
> > > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > > you thank me the first time you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > > (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only inlines
> > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
> (I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
>
> Konstantin
>
Having locking functions inline is already a problem in current releases.
The implementation can not be improved without breaking ABI (or doing special
workarounds like lock v2)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
@ 2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 21:26 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 17:39:07 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, April 15, 2019 4:39 PM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> > <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> > <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Mon, 15 Apr 2019 12:24:47 +0000
> > "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> >
> > > > -----Original Message-----
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Saturday, April 13, 2019 12:06 AM
> > > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> > Gupta
> > > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > > >
> > > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > > >
> > > > > >
> > > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > > >
> > > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > > method.
> > > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > > so that the writers can free the memory associated with the lock less
> > > > > > > data structures.
> > > > > > >
> > > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > > you thank me the first time you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > > (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only inlines
> > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
> (I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
>
> Konstantin
>
Having locking functions inline is already a problem in current releases.
The implementation can not be improved without breaking ABI (or doing special
workarounds like lock v2)
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 18:56 0% ` Honnappa Nagarahalli
@ 2019-04-15 18:56 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-15 18:56 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to
> > > > > > get rid of almost all use of inline and visible structures.
> > > > > > Yes it might be marginally slower, but you thank me the first time
> you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline
> > > > > functions in DPDK? If yes, I think we need to consider the
> > > > > performance
> > > > difference. May be consider L3-fwd application, change all the inline
> functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only
> > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say
> spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want
> it to be as fast as possible (I know that main speedup should come from
> the fact that readers don't have to wait for writer to finish, but still...)
>
Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path.
> Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
@ 2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-15 18:56 UTC (permalink / raw)
To: Ananyev, Konstantin, Stephen Hemminger
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
> > > > > >
> > > > > > After evaluating long term API/ABI issues, I think you need to
> > > > > > get rid of almost all use of inline and visible structures.
> > > > > > Yes it might be marginally slower, but you thank me the first time
> you have to fix something.
> > > > > >
> > > > > Agree, I was planning on another version to address this (I am yet
> to take a look at your patch addressing the ABI).
> > > > > The structure visibility definitely needs to be addressed.
> > > > > For the inline functions, is the plan to convert all the inline
> > > > > functions in DPDK? If yes, I think we need to consider the
> > > > > performance
> > > > difference. May be consider L3-fwd application, change all the inline
> functions in its path and run a test?
> > > >
> > > > Every function that is not in the direct datapath should not be inline.
> > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and
> > > > packet alloc/free
> > >
> > > Plus synchronization routines: spin/rwlock/barrier, etc.
> > > I think rcu should be one of such exceptions - it is just another
> > > synchronization mechanism after all (just a bit more sophisticated).
> > > Konstantin
> >
> > If you look at the other userspace RCU, you wil see that the only
> > inlines are the rcu_read_lock,rcu_read_unlock and
> rcu_reference/rcu_assign_pointer.
> >
> > The synchronization logic is all real functions.
>
> In fact, I think urcu provides both flavors:
> https://github.com/urcu/userspace-
> rcu/blob/master/include/urcu/static/urcu-qsbr.h
> I still don't understand why we have to treat it differently then let say
> spin-lock/ticket-lock or rwlock.
> If we gone all the way to create our own version of rcu, we probably want
> it to be as fast as possible (I know that main speedup should come from
> the fact that readers don't have to wait for writer to finish, but still...)
>
Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path.
> Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 17:39 0% ` Ananyev, Konstantin
@ 2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 17:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, April 15, 2019 4:39 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Mon, 15 Apr 2019 12:24:47 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Saturday, April 13, 2019 12:06 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> Gupta
> > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > >
> > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > > > >
> > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > >
> > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > method.
> > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > so that the writers can free the memory associated with the lock less
> > > > > > data structures.
> > > > > >
> > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > >
> > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > you thank me the first time you have to fix something.
> > > > >
> > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > The structure visibility definitely needs to be addressed.
> > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > >
> > > Every function that is not in the direct datapath should not be inline.
> > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> >
> > Plus synchronization routines: spin/rwlock/barrier, etc.
> > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > (just a bit more sophisticated).
> > Konstantin
>
> If you look at the other userspace RCU, you wil see that the only inlines
> are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
>
> The synchronization logic is all real functions.
In fact, I think urcu provides both flavors:
https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
(I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
@ 2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 17:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, April 15, 2019 4:39 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; paulmck@linux.ibm.com; Kovacevic, Marko
> <marko.kovacevic@intel.com>; dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar
> <Dharmik.Thakkar@arm.com>; Malvika Gupta <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Mon, 15 Apr 2019 12:24:47 +0000
> "Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Saturday, April 13, 2019 12:06 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika
> Gupta
> > > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > >
> > > On Fri, 12 Apr 2019 22:24:45 +0000
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> > >
> > > > >
> > > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > > >
> > > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > > method.
> > > > > > This library helps identify the quiescent state of the reader threads
> > > > > > so that the writers can free the memory associated with the lock less
> > > > > > data structures.
> > > > > >
> > > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > > >
> > > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > > you thank me the first time you have to fix something.
> > > > >
> > > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > > The structure visibility definitely needs to be addressed.
> > > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> > >
> > > Every function that is not in the direct datapath should not be inline.
> > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
> >
> > Plus synchronization routines: spin/rwlock/barrier, etc.
> > I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> > (just a bit more sophisticated).
> > Konstantin
>
> If you look at the other userspace RCU, you wil see that the only inlines
> are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
>
> The synchronization logic is all real functions.
In fact, I think urcu provides both flavors:
https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h
I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock.
If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible
(I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...)
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 15:38 0% ` Stephen Hemminger
@ 2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 15:38 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 12:24:47 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Saturday, April 13, 2019 12:06 AM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Fri, 12 Apr 2019 22:24:45 +0000
> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > >
> > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > >
> > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > method.
> > > > > This library helps identify the quiescent state of the reader threads
> > > > > so that the writers can free the memory associated with the lock less
> > > > > data structures.
> > > > >
> > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > >
> > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > you thank me the first time you have to fix something.
> > > >
> > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > The structure visibility definitely needs to be addressed.
> > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> >
> > Every function that is not in the direct datapath should not be inline.
> > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
>
> Plus synchronization routines: spin/rwlock/barrier, etc.
> I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> (just a bit more sophisticated).
> Konstantin
If you look at the other userspace RCU, you wil see that the only inlines
are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
The synchronization logic is all real functions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
@ 2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-15 15:38 UTC (permalink / raw)
To: Ananyev, Konstantin
Cc: Honnappa Nagarahalli, paulmck, Kovacevic, Marko, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Mon, 15 Apr 2019 12:24:47 +0000
"Ananyev, Konstantin" <konstantin.ananyev@intel.com> wrote:
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Saturday, April 13, 2019 12:06 AM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> > dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> > <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> >
> > On Fri, 12 Apr 2019 22:24:45 +0000
> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > > >
> > > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > > >
> > > > > Add RCU library supporting quiescent state based memory reclamation
> > > > method.
> > > > > This library helps identify the quiescent state of the reader threads
> > > > > so that the writers can free the memory associated with the lock less
> > > > > data structures.
> > > > >
> > > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > >
> > > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > > you thank me the first time you have to fix something.
> > > >
> > > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > > The structure visibility definitely needs to be addressed.
> > > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> > difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> >
> > Every function that is not in the direct datapath should not be inline.
> > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
>
> Plus synchronization routines: spin/rwlock/barrier, etc.
> I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
> (just a bit more sophisticated).
> Konstantin
If you look at the other userspace RCU, you wil see that the only inlines
are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer.
The synchronization logic is all real functions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-15 12:24 0% ` Ananyev, Konstantin
@ 2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 12:24 UTC (permalink / raw)
To: Stephen Hemminger, Honnappa Nagarahalli
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, April 13, 2019 12:06 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Fri, 12 Apr 2019 22:24:45 +0000
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
>
> > >
> > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > >
> > > > Add RCU library supporting quiescent state based memory reclamation
> > > method.
> > > > This library helps identify the quiescent state of the reader threads
> > > > so that the writers can free the memory associated with the lock less
> > > > data structures.
> > > >
> > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > you thank me the first time you have to fix something.
> > >
> > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > The structure visibility definitely needs to be addressed.
> > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
>
> Every function that is not in the direct datapath should not be inline.
> Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
Plus synchronization routines: spin/rwlock/barrier, etc.
I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
(just a bit more sophisticated).
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
@ 2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-15 12:24 UTC (permalink / raw)
To: Stephen Hemminger, Honnappa Nagarahalli
Cc: paulmck, Kovacevic, Marko, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Saturday, April 13, 2019 12:06 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; paulmck@linux.ibm.com; Kovacevic, Marko <marko.kovacevic@intel.com>;
> dev@dpdk.org; Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; Malvika Gupta
> <Malvika.Gupta@arm.com>; nd <nd@arm.com>
> Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
>
> On Fri, 12 Apr 2019 22:24:45 +0000
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
>
> > >
> > > On Fri, 12 Apr 2019 15:20:37 -0500
> > > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> > >
> > > > Add RCU library supporting quiescent state based memory reclamation
> > > method.
> > > > This library helps identify the quiescent state of the reader threads
> > > > so that the writers can free the memory associated with the lock less
> > > > data structures.
> > > >
> > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > > all use of inline and visible structures. Yes it might be marginally slower, but
> > > you thank me the first time you have to fix something.
> > >
> > Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> > The structure visibility definitely needs to be addressed.
> > For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance
> difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
>
> Every function that is not in the direct datapath should not be inline.
> Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
Plus synchronization routines: spin/rwlock/barrier, etc.
I think rcu should be one of such exceptions - it is just another synchronization mechanism after all
(just a bit more sophisticated).
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-15 9:10 4% ` Bruce Richardson
@ 2019-04-15 9:10 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-15 9:10 UTC (permalink / raw)
To: Neil Horman; +Cc: Ray Kinsella, dev
On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote:
> On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> > On 07/04/2019 10:48, Thomas Monjalon wrote:
> > > 04/04/2019 16:07, Burakov, Anatoly:
> > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > [SNIP]
> > >> So, if we are to cement our core API - we have to make a concrete effort
> > >> to specify what goes and what stays, if we want it to be maintainable.
> > >> The DPDK 1.0 specification, if you will :)
> > >
> > > "DPDK 1.0 specification", that's a great project name :-)
> > >
> >
> > Honestly - I would say that I am nervous of this.
> >
> > The definition of a DPDK 1.0 specification as a gate to API stability,
> > feels like a "great plan tomorrow" instead of a "good plan" today. I
> > think that getting people to dedicate time to such a specification might
> > prove problematic and I could see this effort being very time consuming.
> > It might never get completed.
> >
> > My preference would be to instead adopt a well-publicised community
> > timeline for adopting more conservative API maintenance rules.
> >
> > Perhaps we could give ourselves as a community a time-limited window in
> > which to address concerns around the API before they become hardened -
> > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> > to 9 months.
> >
> > We then would know the timeline when niggles like exposure of internal
> > structures and mbuf structure needed to be sorted by and could
> > prioritize accordingly.
> >
> > Ray K
>
> I'm hesitant to say this, because I'm not usually a fan of throwing up
> barricades to progress, but might some level of CI integration be useful here?
>
> Part of the problem, as I've seen it (and I think you've noted previously in
> this thread), is that ABI stability just hasn't been a priority, and not
> something that developers look at when making changes, nor when reviewers review
> patches. When I wrote the early ABI checking tools for DPDK, while the reaction
> was generally positive (I think), the results were informational, and treated as
> such (something to take note of perhaps, but something that could be ignored if
> there were more pressing issues). Perhaps a concrete step might be to run the
> ABI checker during a CI run on every commit, and block acceptance of a patch if
> it modifies the ABI. That would at least put a procedural break in ABI
> modification without clear approval from the board.
>
No objections to that here. Sounds a reasonable suggestion.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
@ 2019-04-15 9:10 4% ` Bruce Richardson
2019-04-15 9:10 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-15 9:10 UTC (permalink / raw)
To: Neil Horman; +Cc: Ray Kinsella, dev
On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote:
> On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> > On 07/04/2019 10:48, Thomas Monjalon wrote:
> > > 04/04/2019 16:07, Burakov, Anatoly:
> > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > [SNIP]
> > >> So, if we are to cement our core API - we have to make a concrete effort
> > >> to specify what goes and what stays, if we want it to be maintainable.
> > >> The DPDK 1.0 specification, if you will :)
> > >
> > > "DPDK 1.0 specification", that's a great project name :-)
> > >
> >
> > Honestly - I would say that I am nervous of this.
> >
> > The definition of a DPDK 1.0 specification as a gate to API stability,
> > feels like a "great plan tomorrow" instead of a "good plan" today. I
> > think that getting people to dedicate time to such a specification might
> > prove problematic and I could see this effort being very time consuming.
> > It might never get completed.
> >
> > My preference would be to instead adopt a well-publicised community
> > timeline for adopting more conservative API maintenance rules.
> >
> > Perhaps we could give ourselves as a community a time-limited window in
> > which to address concerns around the API before they become hardened -
> > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> > to 9 months.
> >
> > We then would know the timeline when niggles like exposure of internal
> > structures and mbuf structure needed to be sorted by and could
> > prioritize accordingly.
> >
> > Ray K
>
> I'm hesitant to say this, because I'm not usually a fan of throwing up
> barricades to progress, but might some level of CI integration be useful here?
>
> Part of the problem, as I've seen it (and I think you've noted previously in
> this thread), is that ABI stability just hasn't been a priority, and not
> something that developers look at when making changes, nor when reviewers review
> patches. When I wrote the early ABI checking tools for DPDK, while the reaction
> was generally positive (I think), the results were informational, and treated as
> such (something to take note of perhaps, but something that could be ignored if
> there were more pressing issues). Perhaps a concrete step might be to run the
> ABI checker during a CI run on every commit, and block acceptance of a patch if
> it modifies the ABI. That would at least put a procedural break in ABI
> modification without clear approval from the board.
>
No objections to that here. Sounds a reasonable suggestion.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-14 0:42 9% ` Neil Horman
@ 2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-14 0:42 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev
On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
> > 04/04/2019 16:07, Burakov, Anatoly:
> >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >> So, if we are to cement our core API - we have to make a concrete effort
> >> to specify what goes and what stays, if we want it to be maintainable.
> >> The DPDK 1.0 specification, if you will :)
> >
> > "DPDK 1.0 specification", that's a great project name :-)
> >
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
I'm hesitant to say this, because I'm not usually a fan of throwing up
barricades to progress, but might some level of CI integration be useful here?
Part of the problem, as I've seen it (and I think you've noted previously in
this thread), is that ABI stability just hasn't been a priority, and not
something that developers look at when making changes, nor when reviewers review
patches. When I wrote the early ABI checking tools for DPDK, while the reaction
was generally positive (I think), the results were informational, and treated as
such (something to take note of perhaps, but something that could be ignored if
there were more pressing issues). Perhaps a concrete step might be to run the
ABI checker during a CI run on every commit, and block acceptance of a patch if
it modifies the ABI. That would at least put a procedural break in ABI
modification without clear approval from the board.
Neil
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-14 0:42 UTC (permalink / raw)
To: Ray Kinsella; +Cc: dev
On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
> > 04/04/2019 16:07, Burakov, Anatoly:
> >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> >>> On 04/04/2019 11:54, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >> So, if we are to cement our core API - we have to make a concrete effort
> >> to specify what goes and what stays, if we want it to be maintainable.
> >> The DPDK 1.0 specification, if you will :)
> >
> > "DPDK 1.0 specification", that's a great project name :-)
> >
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
I'm hesitant to say this, because I'm not usually a fan of throwing up
barricades to progress, but might some level of CI integration be useful here?
Part of the problem, as I've seen it (and I think you've noted previously in
this thread), is that ABI stability just hasn't been a priority, and not
something that developers look at when making changes, nor when reviewers review
patches. When I wrote the early ABI checking tools for DPDK, while the reaction
was generally positive (I think), the results were informational, and treated as
such (something to take note of perhaps, but something that could be ignored if
there were more pressing issues). Perhaps a concrete step might be to run the
ABI checker during a CI run on every commit, and block acceptance of a patch if
it modifies the ABI. That would at least put a procedural break in ABI
modification without clear approval from the board.
Neil
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 23:06 0% ` Stephen Hemminger
@ 2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 23:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Fri, 12 Apr 2019 22:24:45 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > On Fri, 12 Apr 2019 15:20:37 -0500
> > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> >
> > > Add RCU library supporting quiescent state based memory reclamation
> > method.
> > > This library helps identify the quiescent state of the reader threads
> > > so that the writers can free the memory associated with the lock less
> > > data structures.
> > >
> > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > all use of inline and visible structures. Yes it might be marginally slower, but
> > you thank me the first time you have to fix something.
> >
> Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> The structure visibility definitely needs to be addressed.
> For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
Every function that is not in the direct datapath should not be inline.
Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
@ 2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 23:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, nd
On Fri, 12 Apr 2019 22:24:45 +0000
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote:
> >
> > On Fri, 12 Apr 2019 15:20:37 -0500
> > Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> >
> > > Add RCU library supporting quiescent state based memory reclamation
> > method.
> > > This library helps identify the quiescent state of the reader threads
> > > so that the writers can free the memory associated with the lock less
> > > data structures.
> > >
> > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> > After evaluating long term API/ABI issues, I think you need to get rid of almost
> > all use of inline and visible structures. Yes it might be marginally slower, but
> > you thank me the first time you have to fix something.
> >
> Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
> The structure visibility definitely needs to be addressed.
> For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
Every function that is not in the direct datapath should not be inline.
Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet alloc/free
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:24 3% ` Honnappa Nagarahalli
@ 2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-12 22:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
>
> On Fri, 12 Apr 2019 15:20:37 -0500
> Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
>
> > Add RCU library supporting quiescent state based memory reclamation
> method.
> > This library helps identify the quiescent state of the reader threads
> > so that the writers can free the memory associated with the lock less
> > data structures.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> After evaluating long term API/ABI issues, I think you need to get rid of almost
> all use of inline and visible structures. Yes it might be marginally slower, but
> you thank me the first time you have to fix something.
>
Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
The structure visibility definitely needs to be addressed.
For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
@ 2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-12 22:24 UTC (permalink / raw)
To: Stephen Hemminger
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev,
Gavin Hu (Arm Technology China),
Dharmik Thakkar, Malvika Gupta, Honnappa Nagarahalli, nd, nd
>
> On Fri, 12 Apr 2019 15:20:37 -0500
> Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
>
> > Add RCU library supporting quiescent state based memory reclamation
> method.
> > This library helps identify the quiescent state of the reader threads
> > so that the writers can free the memory associated with the lock less
> > data structures.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Steve Capper <steve.capper@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> After evaluating long term API/ABI issues, I think you need to get rid of almost
> all use of inline and visible structures. Yes it might be marginally slower, but
> you thank me the first time you have to fix something.
>
Agree, I was planning on another version to address this (I am yet to take a look at your patch addressing the ABI).
The structure visibility definitely needs to be addressed.
For the inline functions, is the plan to convert all the inline functions in DPDK? If yes, I think we need to consider the performance difference. May be consider L3-fwd application, change all the inline functions in its path and run a test?
> Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
2019-04-12 22:06 3% ` Stephen Hemminger
@ 2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 22:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev, gavin.hu,
dharmik.thakkar, malvika.gupta
On Fri, 12 Apr 2019 15:20:37 -0500
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> Add RCU library supporting quiescent state based memory reclamation method.
> This library helps identify the quiescent state of the reader threads so
> that the writers can free the memory associated with the lock less data
> structures.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
After evaluating long term API/ABI issues, I think you need to get rid
of almost all use of inline and visible structures. Yes it might be marginally
slower, but you thank me the first time you have to fix something.
Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
@ 2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 22:06 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: konstantin.ananyev, paulmck, marko.kovacevic, dev, gavin.hu,
dharmik.thakkar, malvika.gupta
On Fri, 12 Apr 2019 15:20:37 -0500
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> wrote:
> Add RCU library supporting quiescent state based memory reclamation method.
> This library helps identify the quiescent state of the reader threads so
> that the writers can free the memory associated with the lock less data
> structures.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
After evaluating long term API/ABI issues, I think you need to get rid
of almost all use of inline and visible structures. Yes it might be marginally
slower, but you thank me the first time you have to fix something.
Even the log macro should be private.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 16:05 0% ` Stephen Hemminger
@ 2019-04-12 16:05 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-12 16:05 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian
On Fri, 12 Apr 2019 16:32:01 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 26/03/2019 10:29, David Marchand:
> > > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> > wrote:
> > >
> > > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > > Introduce a new api to retrieve per queue statistics from the
> > drivers.
> > > > > The api objectives:
> > > > > - easily add some common per queue statistics and have it exposed
> > > > > through the user xstats api while the user stats api is left
> > untouched
> > > > > - remove the limitations on the per queue statistics count (inherited
> > > > > from ixgbe) and avoid recurrent bugs on stats array overflow
> >
> > First comment, I think it would be easier to read if renaming the legacy
> > basic stats interface was in a separate patch.
> >
>
> It will be quite artificial, but I can do this yes.
>
>
> > > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> > my
> > > > concern is if it is overkill to have three dev_ops to get stats
> > > > and I am feeling that is making xstat code more complex.
> > >
> > > Having these new (meant to be) internal dev_ops has the avantage of
> > > separating the statistics reported from the drivers from the exported
> > api.
> > > This is also why I did not prefix the structure names with rte_.
> >
> > Yes, and to make it clear, please do not talk about API,
> > as it is only a driver interface.
> >
>
> Ok, so I will describe this as a "driver interface" update.
>
>
>
> > > The "complex" part is in a single place, ethdev and this is when
> > > translating from an internal representation to the exposed bits in the
> > > public apis.
> > >
> > > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > > rte_eth_stats'?
> > > >
> > >
> > > It does not solve the problem of drivers that are buggy because of the
> > > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > > All drivers need to be aware of this limitation of the rte_eth_stats
> > > structure.
> >
> > Yes, this limitation should be dropped.
> > I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> > deprecated as they were a bad abstraction of ixgbe limitation.
> >
>
> That's a different topic from my pov, but yes, this mapping stuff should go
> away, later.
>
>
> > > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > > change, so
> > > > fix can be done with less changes, although it will push the fix into
> > next
> > > > release because of the ABI break.
> > >
> > > I am fine with merging this together, we don't want to backport this
> > > anyway, right?
> >
> > No, it would make some behaviours changing in stable releases,
> > so better to not backport it and keep the buggy behaviour in old branches.
> >
>
> Since the time I had posted this RFC, I have worked on a RFC v2, I will
> post this next week, with the drivers I found time to convert.
> We will have to take a decision on what goes to -rc2 between this and the
> q_errors[] patchset.
>
>
It looks like this all about maintaining source compatiablity with older
or out of tree drivers. This is not something DPDK has to worry about.
Why not just do a mondo patch that fixes all the drivers to use the new stats API.
You do need to keep the same ethdev interface for applications, but driver
API can change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
@ 2019-04-12 16:05 0% ` Stephen Hemminger
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-12 16:05 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian
On Fri, 12 Apr 2019 16:32:01 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 26/03/2019 10:29, David Marchand:
> > > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> > wrote:
> > >
> > > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > > Introduce a new api to retrieve per queue statistics from the
> > drivers.
> > > > > The api objectives:
> > > > > - easily add some common per queue statistics and have it exposed
> > > > > through the user xstats api while the user stats api is left
> > untouched
> > > > > - remove the limitations on the per queue statistics count (inherited
> > > > > from ixgbe) and avoid recurrent bugs on stats array overflow
> >
> > First comment, I think it would be easier to read if renaming the legacy
> > basic stats interface was in a separate patch.
> >
>
> It will be quite artificial, but I can do this yes.
>
>
> > > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> > my
> > > > concern is if it is overkill to have three dev_ops to get stats
> > > > and I am feeling that is making xstat code more complex.
> > >
> > > Having these new (meant to be) internal dev_ops has the avantage of
> > > separating the statistics reported from the drivers from the exported
> > api.
> > > This is also why I did not prefix the structure names with rte_.
> >
> > Yes, and to make it clear, please do not talk about API,
> > as it is only a driver interface.
> >
>
> Ok, so I will describe this as a "driver interface" update.
>
>
>
> > > The "complex" part is in a single place, ethdev and this is when
> > > translating from an internal representation to the exposed bits in the
> > > public apis.
> > >
> > > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > > rte_eth_stats'?
> > > >
> > >
> > > It does not solve the problem of drivers that are buggy because of the
> > > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > > All drivers need to be aware of this limitation of the rte_eth_stats
> > > structure.
> >
> > Yes, this limitation should be dropped.
> > I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> > deprecated as they were a bad abstraction of ixgbe limitation.
> >
>
> That's a different topic from my pov, but yes, this mapping stuff should go
> away, later.
>
>
> > > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > > change, so
> > > > fix can be done with less changes, although it will push the fix into
> > next
> > > > release because of the ABI break.
> > >
> > > I am fine with merging this together, we don't want to backport this
> > > anyway, right?
> >
> > No, it would make some behaviours changing in stable releases,
> > so better to not backport it and keep the buggy behaviour in old branches.
> >
>
> Since the time I had posted this RFC, I have worked on a RFC v2, I will
> post this next week, with the drivers I found time to convert.
> We will have to take a decision on what goes to -rc2 between this and the
> q_errors[] patchset.
>
>
It looks like this all about maintaining source compatiablity with older
or out of tree drivers. This is not something DPDK has to worry about.
Why not just do a mondo patch that fixes all the drivers to use the new stats API.
You do need to keep the same ethdev interface for applications, but driver
API can change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:57 0% ` Ferruh Yigit
@ 2019-04-12 15:57 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:45 PM, Thomas Monjalon wrote:
> 12/04/2019 17:38, Ferruh Yigit:
>> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
>>> 11/03/2019 18:22, Ferruh Yigit:
>>>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>>>> According to the api, the q_errors[] per queue statistic is for reception
>>>>> errors not transmit errors.
>>>>> This is a first cleanup on statistics before looking at oerrors.
>>>>>
>>>>
>>>> Yes, the patchset looks aligned with the API documentation [1].
>>>>
>>>> What can be the solution after cleanup? We can merge this cleanup and solution
>>>> next to each-other to not leave a gap?
>>>
>>> I think we should merge those fixes in 19.05-rc2.
>>>
>>> It seems there is a lot more work to achieve on stats, so better
>>> to start without waiting for the full picture.
>>>
>>
>> The problem is "q_errors" is available only for Rx queues, and David's patch is
>> preventing drivers to put Tx error stats into "q_errors" field.
>>
>> But it is clear that there is a need for a field for Tx queues errors. David has
>> another patch to using xstats for this. But I believe xstats is making solution
>> confusing, and now approach is unbalanced for Rx and Tx queues.
>>
>> I am for adding a new field for Tx queues "q_errors", and this will make getting
>> stats and David's patch very simple.
>>
>> The problem with the new fields is it breaks the ABI, but we already increased
>> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
>
> If changing the stats API, we should increase the number of stats per queue:
> #define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
> What about 128 queues per port? 256?
We have 5 uint64_t using this [1], it will be 6 if we add new one.
So having 256 queues, will cost 12K memory, this is not a big number.
Is there any other concern of having large array other than possible memory waste?
[1]
uint64_t q_ipackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_ibytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_obytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS];
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
@ 2019-04-12 15:57 0% ` Ferruh Yigit
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:45 PM, Thomas Monjalon wrote:
> 12/04/2019 17:38, Ferruh Yigit:
>> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
>>> 11/03/2019 18:22, Ferruh Yigit:
>>>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>>>> According to the api, the q_errors[] per queue statistic is for reception
>>>>> errors not transmit errors.
>>>>> This is a first cleanup on statistics before looking at oerrors.
>>>>>
>>>>
>>>> Yes, the patchset looks aligned with the API documentation [1].
>>>>
>>>> What can be the solution after cleanup? We can merge this cleanup and solution
>>>> next to each-other to not leave a gap?
>>>
>>> I think we should merge those fixes in 19.05-rc2.
>>>
>>> It seems there is a lot more work to achieve on stats, so better
>>> to start without waiting for the full picture.
>>>
>>
>> The problem is "q_errors" is available only for Rx queues, and David's patch is
>> preventing drivers to put Tx error stats into "q_errors" field.
>>
>> But it is clear that there is a need for a field for Tx queues errors. David has
>> another patch to using xstats for this. But I believe xstats is making solution
>> confusing, and now approach is unbalanced for Rx and Tx queues.
>>
>> I am for adding a new field for Tx queues "q_errors", and this will make getting
>> stats and David's patch very simple.
>>
>> The problem with the new fields is it breaks the ABI, but we already increased
>> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
>
> If changing the stats API, we should increase the number of stats per queue:
> #define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
> What about 128 queues per port? 256?
We have 5 uint64_t using this [1], it will be 6 if we add new one.
So having 256 queues, will cost 12K memory, this is not a big number.
Is there any other concern of having large array other than possible memory waste?
[1]
uint64_t q_ipackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_ibytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_obytes[RTE_ETHDEV_QUEUE_STAT_CNTRS];
uint64_t q_errors[RTE_ETHDEV_QUEUE_STAT_CNTRS];
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:45 0% ` Thomas Monjalon
@ 2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 15:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, David Marchand, Andrew Rybchenko
12/04/2019 17:38, Ferruh Yigit:
> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> > 11/03/2019 18:22, Ferruh Yigit:
> >> On 3/4/2019 11:18 AM, David Marchand wrote:
> >>> According to the api, the q_errors[] per queue statistic is for reception
> >>> errors not transmit errors.
> >>> This is a first cleanup on statistics before looking at oerrors.
> >>>
> >>
> >> Yes, the patchset looks aligned with the API documentation [1].
> >>
> >> What can be the solution after cleanup? We can merge this cleanup and solution
> >> next to each-other to not leave a gap?
> >
> > I think we should merge those fixes in 19.05-rc2.
> >
> > It seems there is a lot more work to achieve on stats, so better
> > to start without waiting for the full picture.
> >
>
> The problem is "q_errors" is available only for Rx queues, and David's patch is
> preventing drivers to put Tx error stats into "q_errors" field.
>
> But it is clear that there is a need for a field for Tx queues errors. David has
> another patch to using xstats for this. But I believe xstats is making solution
> confusing, and now approach is unbalanced for Rx and Tx queues.
>
> I am for adding a new field for Tx queues "q_errors", and this will make getting
> stats and David's patch very simple.
>
> The problem with the new fields is it breaks the ABI, but we already increased
> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
If changing the stats API, we should increase the number of stats per queue:
#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
What about 128 queues per port? 256?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
@ 2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 15:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, David Marchand, Andrew Rybchenko
12/04/2019 17:38, Ferruh Yigit:
> On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> > 11/03/2019 18:22, Ferruh Yigit:
> >> On 3/4/2019 11:18 AM, David Marchand wrote:
> >>> According to the api, the q_errors[] per queue statistic is for reception
> >>> errors not transmit errors.
> >>> This is a first cleanup on statistics before looking at oerrors.
> >>>
> >>
> >> Yes, the patchset looks aligned with the API documentation [1].
> >>
> >> What can be the solution after cleanup? We can merge this cleanup and solution
> >> next to each-other to not leave a gap?
> >
> > I think we should merge those fixes in 19.05-rc2.
> >
> > It seems there is a lot more work to achieve on stats, so better
> > to start without waiting for the full picture.
> >
>
> The problem is "q_errors" is available only for Rx queues, and David's patch is
> preventing drivers to put Tx error stats into "q_errors" field.
>
> But it is clear that there is a need for a field for Tx queues errors. David has
> another patch to using xstats for this. But I believe xstats is making solution
> confusing, and now approach is unbalanced for Rx and Tx queues.
>
> I am for adding a new field for Tx queues "q_errors", and this will make getting
> stats and David's patch very simple.
>
> The problem with the new fields is it breaks the ABI, but we already increased
> the ABIVER for ethdev this release, I believe this is very good timing for this fix.
If changing the stats API, we should increase the number of stats per queue:
#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
What about 128 queues per port? 256?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
2019-04-12 15:38 3% ` Ferruh Yigit
@ 2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> 11/03/2019 18:22, Ferruh Yigit:
>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>> According to the api, the q_errors[] per queue statistic is for reception
>>> errors not transmit errors.
>>> This is a first cleanup on statistics before looking at oerrors.
>>>
>>
>> Yes, the patchset looks aligned with the API documentation [1].
>>
>> What can be the solution after cleanup? We can merge this cleanup and solution
>> next to each-other to not leave a gap?
>
> I think we should merge those fixes in 19.05-rc2.
>
> It seems there is a lot more work to achieve on stats, so better
> to start without waiting for the full picture.
>
The problem is "q_errors" is available only for Rx queues, and David's patch is
preventing drivers to put Tx error stats into "q_errors" field.
But it is clear that there is a need for a field for Tx queues errors. David has
another patch to using xstats for this. But I believe xstats is making solution
confusing, and now approach is unbalanced for Rx and Tx queues.
I am for adding a new field for Tx queues "q_errors", and this will make getting
stats and David's patch very simple.
The problem with the new fields is it breaks the ABI, but we already increased
the ABIVER for ethdev this release, I believe this is very good timing for this fix.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes
@ 2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-12 15:38 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Andrew Rybchenko
On 4/12/2019 4:07 PM, Thomas Monjalon wrote:
> 11/03/2019 18:22, Ferruh Yigit:
>> On 3/4/2019 11:18 AM, David Marchand wrote:
>>> According to the api, the q_errors[] per queue statistic is for reception
>>> errors not transmit errors.
>>> This is a first cleanup on statistics before looking at oerrors.
>>>
>>
>> Yes, the patchset looks aligned with the API documentation [1].
>>
>> What can be the solution after cleanup? We can merge this cleanup and solution
>> next to each-other to not leave a gap?
>
> I think we should merge those fixes in 19.05-rc2.
>
> It seems there is a lot more work to achieve on stats, so better
> to start without waiting for the full picture.
>
The problem is "q_errors" is available only for Rx queues, and David's patch is
preventing drivers to put Tx error stats into "q_errors" field.
But it is clear that there is a need for a field for Tx queues errors. David has
another patch to using xstats for this. But I believe xstats is making solution
confusing, and now approach is unbalanced for Rx and Tx queues.
I am for adding a new field for Tx queues "q_errors", and this will make getting
stats and David's patch very simple.
The problem with the new fields is it breaks the ABI, but we already increased
the ABIVER for ethdev this release, I believe this is very good timing for this fix.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 14:32 0% ` David Marchand
@ 2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-12 14:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> 26/03/2019 10:29, David Marchand:
> > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> >
> > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > Introduce a new api to retrieve per queue statistics from the
> drivers.
> > > > The api objectives:
> > > > - easily add some common per queue statistics and have it exposed
> > > > through the user xstats api while the user stats api is left
> untouched
> > > > - remove the limitations on the per queue statistics count (inherited
> > > > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> First comment, I think it would be easier to read if renaming the legacy
> basic stats interface was in a separate patch.
>
It will be quite artificial, but I can do this yes.
> > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> my
> > > concern is if it is overkill to have three dev_ops to get stats
> > > and I am feeling that is making xstat code more complex.
> >
> > Having these new (meant to be) internal dev_ops has the avantage of
> > separating the statistics reported from the drivers from the exported
> api.
> > This is also why I did not prefix the structure names with rte_.
>
> Yes, and to make it clear, please do not talk about API,
> as it is only a driver interface.
>
Ok, so I will describe this as a "driver interface" update.
> > The "complex" part is in a single place, ethdev and this is when
> > translating from an internal representation to the exposed bits in the
> > public apis.
> >
> > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > rte_eth_stats'?
> > >
> >
> > It does not solve the problem of drivers that are buggy because of the
> > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > All drivers need to be aware of this limitation of the rte_eth_stats
> > structure.
>
> Yes, this limitation should be dropped.
> I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> deprecated as they were a bad abstraction of ixgbe limitation.
>
That's a different topic from my pov, but yes, this mapping stuff should go
away, later.
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > change, so
> > > fix can be done with less changes, although it will push the fix into
> next
> > > release because of the ABI break.
> >
> > I am fine with merging this together, we don't want to backport this
> > anyway, right?
>
> No, it would make some behaviours changing in stable releases,
> so better to not backport it and keep the buggy behaviour in old branches.
>
Since the time I had posted this RFC, I have worked on a RFC v2, I will
post this next week, with the drivers I found time to convert.
We will have to take a decision on what goes to -rc2 between this and the
q_errors[] patchset.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
@ 2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2019-04-12 14:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
On Fri, Apr 12, 2019 at 3:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> 26/03/2019 10:29, David Marchand:
> > On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> >
> > > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > > Introduce a new api to retrieve per queue statistics from the
> drivers.
> > > > The api objectives:
> > > > - easily add some common per queue statistics and have it exposed
> > > > through the user xstats api while the user stats api is left
> untouched
> > > > - remove the limitations on the per queue statistics count (inherited
> > > > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> First comment, I think it would be easier to read if renaming the legacy
> basic stats interface was in a separate patch.
>
It will be quite artificial, but I can do this yes.
> > > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get',
> my
> > > concern is if it is overkill to have three dev_ops to get stats
> > > and I am feeling that is making xstat code more complex.
> >
> > Having these new (meant to be) internal dev_ops has the avantage of
> > separating the statistics reported from the drivers from the exported
> api.
> > This is also why I did not prefix the structure names with rte_.
>
> Yes, and to make it clear, please do not talk about API,
> as it is only a driver interface.
>
Ok, so I will describe this as a "driver interface" update.
> > The "complex" part is in a single place, ethdev and this is when
> > translating from an internal representation to the exposed bits in the
> > public apis.
> >
> > Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > > rte_eth_stats'?
> > >
> >
> > It does not solve the problem of drivers that are buggy because of the
> > limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> > All drivers need to be aware of this limitation of the rte_eth_stats
> > structure.
>
> Yes, this limitation should be dropped.
> I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
> deprecated as they were a bad abstraction of ixgbe limitation.
>
That's a different topic from my pov, but yes, this mapping stuff should go
away, later.
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > > change, so
> > > fix can be done with less changes, although it will push the fix into
> next
> > > release because of the ABI break.
> >
> > I am fine with merging this together, we don't want to backport this
> > anyway, right?
>
> No, it would make some behaviours changing in stable releases,
> so better to not backport it and keep the buggy behaviour in old branches.
>
Since the time I had posted this RFC, I have worked on a RFC v2, I will
post this next week, with the drivers I found time to convert.
We will have to take a decision on what goes to -rc2 between this and the
q_errors[] patchset.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-04-12 13:29 0% ` Thomas Monjalon
@ 2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 13:29 UTC (permalink / raw)
To: David Marchand
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
26/03/2019 10:29, David Marchand:
> On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > Introduce a new api to retrieve per queue statistics from the drivers.
> > > The api objectives:
> > > - easily add some common per queue statistics and have it exposed
> > > through the user xstats api while the user stats api is left untouched
> > > - remove the limitations on the per queue statistics count (inherited
> > > from ixgbe) and avoid recurrent bugs on stats array overflow
First comment, I think it would be easier to read if renaming the legacy
basic stats interface was in a separate patch.
> > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> > concern is if it is overkill to have three dev_ops to get stats
> > and I am feeling that is making xstat code more complex.
>
> Having these new (meant to be) internal dev_ops has the avantage of
> separating the statistics reported from the drivers from the exported api.
> This is also why I did not prefix the structure names with rte_.
Yes, and to make it clear, please do not talk about API,
as it is only a driver interface.
> The "complex" part is in a single place, ethdev and this is when
> translating from an internal representation to the exposed bits in the
> public apis.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > rte_eth_stats'?
> >
>
> It does not solve the problem of drivers that are buggy because of the
> limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> All drivers need to be aware of this limitation of the rte_eth_stats
> structure.
Yes, this limitation should be dropped.
I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
deprecated as they were a bad abstraction of ixgbe limitation.
> The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
> having rxq/txq_stats_get dev_ops is more consistent to me.
+1
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > change, so
> > fix can be done with less changes, although it will push the fix into next
> > release because of the ABI break.
>
> I am fine with merging this together, we don't want to backport this
> anyway, right?
No, it would make some behaviours changing in stable releases,
so better to not backport it and keep the buggy behaviour in old branches.
> But so far, I don't feel the need to break the rte_eth_stats_get API, if we
> want to go to this, we can define an entirely new api to expose
> standardized bits and still use the rxq/txq_stats_get internal dev_ops I
> propose.
Good
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
@ 2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-12 13:29 UTC (permalink / raw)
To: David Marchand
Cc: dev, Ferruh Yigit, Andrew Rybchenko, Stokes, Ian, Stephen Hemminger
26/03/2019 10:29, David Marchand:
> On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> > On 3/14/2019 3:13 PM, David Marchand wrote:
> > > Introduce a new api to retrieve per queue statistics from the drivers.
> > > The api objectives:
> > > - easily add some common per queue statistics and have it exposed
> > > through the user xstats api while the user stats api is left untouched
> > > - remove the limitations on the per queue statistics count (inherited
> > > from ixgbe) and avoid recurrent bugs on stats array overflow
First comment, I think it would be easier to read if renaming the legacy
basic stats interface was in a separate patch.
> > The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> > concern is if it is overkill to have three dev_ops to get stats
> > and I am feeling that is making xstat code more complex.
>
> Having these new (meant to be) internal dev_ops has the avantage of
> separating the statistics reported from the drivers from the exported api.
> This is also why I did not prefix the structure names with rte_.
Yes, and to make it clear, please do not talk about API,
as it is only a driver interface.
> The "complex" part is in a single place, ethdev and this is when
> translating from an internal representation to the exposed bits in the
> public apis.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> > rte_eth_stats'?
> >
>
> It does not solve the problem of drivers that are buggy because of the
> limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
> All drivers need to be aware of this limitation of the rte_eth_stats
> structure.
Yes, this limitation should be dropped.
I would like to see the functions rte_eth_dev_set_?x_queue_stats_mapping()
deprecated as they were a bad abstraction of ixgbe limitation.
> The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
> having rxq/txq_stats_get dev_ops is more consistent to me.
+1
> > And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> > change, so
> > fix can be done with less changes, although it will push the fix into next
> > release because of the ABI break.
>
> I am fine with merging this together, we don't want to backport this
> anyway, right?
No, it would make some behaviours changing in stable releases,
so better to not backport it and keep the buggy behaviour in old branches.
> But so far, I don't feel the need to break the rte_eth_stats_get API, if we
> want to go to this, we can define an entirely new api to expose
> standardized bits and still use the rxq/txq_stats_get internal dev_ops I
> propose.
Good
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH V3] doc: add guideines for initial PMD submission
2019-04-12 10:26 4% [dpdk-dev] [PATCH V3] " Rami Rosen
@ 2019-04-12 10:26 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-12 10:26 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V3 changes:
* Fix a typo.
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, initial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V3] doc: add guideines for initial PMD submission
@ 2019-04-12 10:26 4% Rami Rosen
2019-04-12 10:26 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-12 10:26 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V3 changes:
* Fix a typo.
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, initial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission
2019-04-12 10:13 4% [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission Rami Rosen
@ 2019-04-12 10:13 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-12 10:13 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, intial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission
@ 2019-04-12 10:13 4% Rami Rosen
2019-04-12 10:13 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-12 10:13 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, akhil.goyal, john.mcnamara, marko.kovacevic, stable,
Rami Rosen
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for example, for new
network ethernet PMDs it should be dpdk-next-net, and for new crypto
PMDs it should be dpdk-next-crypto. For other new PMDs, the
contributor should refer to the MAINTAINERS file. Though this may seem
obvious, it is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
V2 changes:
* Fix according to feedback from Fiona Trahe and Akhil Goyal.
doc/guides/contributing/patches.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..110cac41e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,14 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* Initial submission of new PMDs should be prepared against a corresponding repo.
+
+* Thus, for example, initial submission of a new network PMD should be prepared against dpdk-next-net repo.
+
+* Likewise, intial submission of a new crypto or compression PMD should be prepared against dpdk-next-crypto repo.
+
+* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums
2019-04-11 10:41 1% [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums Bruce Richardson
@ 2019-04-11 10:41 1% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-11 10:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The cmdline defined an enum for the various numeric type parameters,
but these were missing the RTE_ prefix and so could conflict with defines
in various environments, e.g. on Windows. Adding the prefix fixes these
conflicts.
Note: this changes the API used by apps using cmdline, but since enum
values aren't changing, it's ABI compatible.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test-cmdline/commands.c | 2 +-
app/test-pmd/bpf_cmd.c | 8 +-
app/test-pmd/cmdline.c | 656 +++++++++---------
app/test-pmd/cmdline_mtr.c | 84 +--
app/test-pmd/cmdline_tm.c | 172 ++---
app/test/test_cmdline_num.c | 48 +-
doc/guides/rel_notes/release_19_05.rst | 4 +
examples/ethtool/ethtool-app/ethapp.c | 18 +-
examples/ipsec-secgw/parser.c | 2 +-
examples/qos_sched/cmdline.c | 46 +-
examples/quota_watermark/qwctl/commands.c | 2 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/vm_power_cli.c | 8 +-
lib/librte_cmdline/cmdline_parse_num.c | 40 +-
lib/librte_cmdline/cmdline_parse_num.h | 16 +-
15 files changed, 556 insertions(+), 552 deletions(-)
diff --git a/app/test-cmdline/commands.c b/app/test-cmdline/commands.c
index d81da9665..0e2ca8ac4 100644
--- a/app/test-cmdline/commands.c
+++ b/app/test-cmdline/commands.c
@@ -191,7 +191,7 @@ cmd_num_parsed(void *parsed_result,
}
cmdline_parse_token_num_t cmd_num_tok =
- TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, RTE_UINT32);
cmdline_parse_inst_t cmd_num = {
.f = cmd_num_parsed, /* function to call */
diff --git a/app/test-pmd/bpf_cmd.c b/app/test-pmd/bpf_cmd.c
index 830bfc13a..254290f30 100644
--- a/app/test-pmd/bpf_cmd.c
+++ b/app/test-pmd/bpf_cmd.c
@@ -124,9 +124,9 @@ cmdline_parse_token_string_t cmd_load_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_load_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_load_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, RTE_UINT16);
cmdline_parse_token_string_t cmd_load_bpf_flags =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
flags, NULL);
@@ -180,9 +180,9 @@ cmdline_parse_token_string_t cmd_unload_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_unld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_unload_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_unload_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_bpf_unld_parse = {
.f = cmd_operate_bpf_unld_parsed,
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ab03c111..82e67ab92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1250,7 +1250,7 @@ cmdline_parse_token_string_t cmd_operate_specific_port_port =
name, "start#stop#close#reset");
cmdline_parse_token_num_t cmd_operate_specific_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_inst_t cmd_operate_specific_port = {
.f = cmd_operate_specific_port_parsed,
@@ -1386,7 +1386,7 @@ cmdline_parse_token_string_t cmd_operate_detach_port_keyword =
keyword, "detach");
cmdline_parse_token_num_t cmd_operate_detach_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_detach_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_detach_port = {
.f = cmd_operate_detach_port_parsed,
@@ -1567,7 +1567,7 @@ cmdline_parse_token_string_t cmd_config_speed_specific_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, keyword,
"config");
cmdline_parse_token_num_t cmd_config_speed_specific_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_speed_specific_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item1,
"speed");
@@ -1639,7 +1639,7 @@ cmdline_parse_token_string_t cmd_config_loopback_all_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_all, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_all_mode =
- TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_all = {
.f = cmd_config_loopback_all_parsed,
@@ -1693,13 +1693,13 @@ cmdline_parse_token_string_t cmd_config_loopback_specific_keyword =
"config");
cmdline_parse_token_num_t cmd_config_loopback_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_loopback_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_specific, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_specific_mode =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, mode,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_specific = {
.f = cmd_config_loopback_specific_parsed,
@@ -1789,7 +1789,7 @@ cmdline_parse_token_string_t cmd_config_rx_tx_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rx_tx, name,
"rxq#txq#rxd#txd");
cmdline_parse_token_num_t cmd_config_rx_tx_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rx_tx = {
.f = cmd_config_rx_tx_parsed,
@@ -1871,7 +1871,7 @@ cmdline_parse_token_string_t cmd_config_max_pkt_len_name =
"max-pkt-len");
cmdline_parse_token_num_t cmd_config_max_pkt_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_max_pkt_len_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_max_pkt_len = {
.f = cmd_config_max_pkt_len_parsed,
@@ -1920,9 +1920,9 @@ cmdline_parse_token_string_t cmd_config_mtu_mtu =
TOKEN_STRING_INITIALIZER(struct cmd_config_mtu_result, keyword,
"mtu");
cmdline_parse_token_num_t cmd_config_mtu_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_config_mtu_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_mtu = {
.f = cmd_config_mtu_parsed,
@@ -2287,7 +2287,7 @@ cmdline_parse_token_string_t cmd_config_rss_hash_key_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key, config,
"config");
cmdline_parse_token_num_t cmd_config_rss_hash_key_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_hash_key_rss_hash_key =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key,
rss_hash_key, "rss-hash-key");
@@ -2385,19 +2385,19 @@ cmdline_parse_token_string_t cmd_config_rxtx_ring_size_config =
config, "config");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_portid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- portid, UINT16);
+ portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rsize =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rsize, "ring_size");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- size, UINT16);
+ size, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rxtx_ring_size = {
.f = cmd_config_rxtx_ring_size_parsed,
@@ -2486,11 +2486,11 @@ cmd_config_rxtx_queue_parsed(void *parsed_result,
cmdline_parse_token_string_t cmd_config_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_config_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, opname,
"start#stop");
@@ -2566,13 +2566,13 @@ cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_port =
port, "port");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
opname, "deferred_start");
@@ -2608,11 +2608,11 @@ struct cmd_setup_rxtx_queue {
cmdline_parse_token_string_t cmd_setup_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_setup =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, setup, "setup");
@@ -2819,7 +2819,7 @@ cmdline_parse_token_string_t cmd_config_rss_reta_port =
cmdline_parse_token_string_t cmd_config_rss_reta_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, keyword, "config");
cmdline_parse_token_num_t cmd_config_rss_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_reta_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, name, "rss");
cmdline_parse_token_string_t cmd_config_rss_reta_list_name =
@@ -2927,13 +2927,13 @@ cmdline_parse_token_string_t cmd_showport_reta_show =
cmdline_parse_token_string_t cmd_showport_reta_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
cmdline_parse_token_num_t cmd_showport_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_rss =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
cmdline_parse_token_string_t cmd_showport_reta_reta =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
cmdline_parse_token_num_t cmd_showport_reta_size =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_list_of_items =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta,
list_of_items, NULL);
@@ -2978,7 +2978,7 @@ cmdline_parse_token_string_t cmd_showport_rss_hash_show =
cmdline_parse_token_string_t cmd_showport_rss_hash_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, port, "port");
cmdline_parse_token_num_t cmd_showport_rss_hash_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_rss_hash_rss_hash =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, rss_hash,
"rss-hash");
@@ -3082,7 +3082,7 @@ cmdline_parse_token_string_t cmd_config_dcb_port =
cmdline_parse_token_string_t cmd_config_dcb_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, config, "config");
cmdline_parse_token_num_t cmd_config_dcb_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_dcb_dcb =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, dcb, "dcb");
cmdline_parse_token_string_t cmd_config_dcb_vt =
@@ -3090,7 +3090,7 @@ cmdline_parse_token_string_t cmd_config_dcb_vt =
cmdline_parse_token_string_t cmd_config_dcb_vt_en =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, vt_en, "on#off");
cmdline_parse_token_num_t cmd_config_dcb_num_tcs =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_dcb_pfc=
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, pfc, "pfc");
cmdline_parse_token_string_t cmd_config_dcb_pfc_en =
@@ -3185,7 +3185,7 @@ cmdline_parse_token_string_t cmd_config_burst_all =
cmdline_parse_token_string_t cmd_config_burst_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_burst, name, "burst");
cmdline_parse_token_num_t cmd_config_burst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_burst = {
.f = cmd_config_burst_parsed,
@@ -3254,7 +3254,7 @@ cmdline_parse_token_string_t cmd_config_thresh_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_thresh, name,
"txpt#txht#txwt#rxpt#rxht#rxwt");
cmdline_parse_token_num_t cmd_config_thresh_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, RTE_UINT8);
cmdline_parse_inst_t cmd_config_thresh = {
.f = cmd_config_thresh_parsed,
@@ -3318,7 +3318,7 @@ cmdline_parse_token_string_t cmd_config_threshold_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_threshold, name,
"txfreet#txrst#rxfreet");
cmdline_parse_token_num_t cmd_config_threshold_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_threshold = {
.f = cmd_config_threshold_parsed,
@@ -3524,7 +3524,7 @@ cmdline_parse_token_string_t cmd_setmask_mask =
TOKEN_STRING_INITIALIZER(struct cmd_setmask_result, mask,
"coremask#portmask");
cmdline_parse_token_num_t cmd_setmask_value =
- TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, RTE_UINT64);
cmdline_parse_inst_t cmd_set_fwd_mask = {
.f = cmd_set_mask_parsed,
@@ -3570,7 +3570,7 @@ cmdline_parse_token_string_t cmd_set_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, what,
"nbport#nbcore#burst#verbose");
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_set_numbers = {
.f = cmd_set_parsed,
@@ -3618,7 +3618,7 @@ cmdline_parse_token_string_t cmd_set_log_log =
cmdline_parse_token_string_t cmd_set_log_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_log_result, type, NULL);
cmdline_parse_token_num_t cmd_set_log_level =
- TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, RTE_UINT32);
cmdline_parse_inst_t cmd_set_log = {
.f = cmd_set_log_parsed,
@@ -3752,7 +3752,7 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_all_all =
all, "all");
cmdline_parse_token_num_t cmd_rx_vlan_filter_all_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_all_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter_all = {
.f = cmd_rx_vlan_filter_all_parsed,
@@ -3914,10 +3914,10 @@ cmdline_parse_token_string_t cmd_vlan_tpid_what =
what, "tpid");
cmdline_parse_token_num_t cmd_vlan_tpid_tpid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- tp_id, UINT16);
+ tp_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vlan_tpid_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
@@ -3964,10 +3964,10 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter = {
.f = cmd_rx_vlan_filter_parsed,
@@ -4017,10 +4017,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set = {
.f = cmd_tx_vlan_set_parsed,
@@ -4071,13 +4071,13 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_qinq_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid_outer =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id_outer, UINT16);
+ vlan_id_outer, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set_qinq = {
.f = cmd_tx_vlan_set_qinq_parsed,
@@ -4129,10 +4129,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_pvid =
pvid, "pvid");
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_vlan_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_mode =
TOKEN_STRING_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
mode, "on#off");
@@ -4184,7 +4184,7 @@ cmdline_parse_token_string_t cmd_tx_vlan_reset_reset =
reset, "reset");
cmdline_parse_token_num_t cmd_tx_vlan_reset_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_reset = {
.f = cmd_tx_vlan_reset_parsed,
@@ -4370,7 +4370,7 @@ cmdline_parse_token_string_t cmd_csum_hwsw =
hwsw, "hw#sw");
cmdline_parse_token_num_t cmd_csum_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_set = {
.f = cmd_csum_parsed,
@@ -4441,7 +4441,7 @@ cmdline_parse_token_string_t cmd_csum_tunnel_onoff =
onoff, "on#off");
cmdline_parse_token_num_t cmd_csum_tunnel_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_tunnel_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_tunnel = {
.f = cmd_csum_tunnel_parsed,
@@ -4521,10 +4521,10 @@ cmdline_parse_token_string_t cmd_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tso_set = {
.f = cmd_tso_set_parsed,
@@ -4667,10 +4667,10 @@ cmdline_parse_token_string_t cmd_tunnel_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tunnel_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_tso_set = {
.f = cmd_tunnel_tso_set_parsed,
@@ -4734,7 +4734,7 @@ cmdline_parse_token_string_t cmd_gro_enable_port =
cmd_keyword, "port");
cmdline_parse_token_num_t cmd_gro_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_enable_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
cmd_keyword, "gro");
@@ -4784,7 +4784,7 @@ cmdline_parse_token_string_t cmd_gro_show_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_gro_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_show_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_show_result,
cmd_keyword, "gro");
@@ -4834,7 +4834,7 @@ cmdline_parse_token_string_t cmd_gro_flush_flush =
cmd_flush, "flush");
cmdline_parse_token_num_t cmd_gro_flush_cycles =
TOKEN_NUM_INITIALIZER(struct cmd_gro_flush_result,
- cmd_cycles, UINT8);
+ cmd_cycles, RTE_UINT8);
cmdline_parse_inst_t cmd_gro_flush = {
.f = cmd_gro_flush_parsed,
@@ -4884,7 +4884,7 @@ cmdline_parse_token_string_t cmd_gso_enable_mode =
cmd_mode, "on#off");
cmdline_parse_token_num_t cmd_gso_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_enable = {
.f = cmd_gso_enable_parsed,
@@ -4943,7 +4943,7 @@ cmdline_parse_token_string_t cmd_gso_size_segsz =
cmd_segsz, "segsz");
cmdline_parse_token_num_t cmd_gso_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_gso_size_result,
- cmd_size, UINT16);
+ cmd_size, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_size = {
.f = cmd_gso_size_parsed,
@@ -5001,7 +5001,7 @@ cmdline_parse_token_string_t cmd_gso_show_keyword =
cmd_keyword, "gso");
cmdline_parse_token_num_t cmd_gso_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_show = {
.f = cmd_gso_show_parsed,
@@ -5144,7 +5144,7 @@ cmdline_parse_token_string_t cmd_setbypass_mode_value =
value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_mode = {
.f = cmd_set_bypass_mode_parsed,
@@ -5250,7 +5250,7 @@ cmdline_parse_token_string_t cmd_setbypass_event_mode_value =
mode_value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_event_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_event_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_event = {
.f = cmd_set_bypass_event_parsed,
@@ -5417,7 +5417,7 @@ cmdline_parse_token_string_t cmd_showbypass_config_config =
config, "config");
cmdline_parse_token_num_t cmd_showbypass_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bypass_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bypass_config = {
.f = cmd_show_bypass_config_parsed,
@@ -5466,10 +5466,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
mode, "mode");
cmdline_parse_token_num_t cmd_setbonding_mode_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_token_num_t cmd_setbonding_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_mode = {
.f = cmd_set_bonding_mode_parsed,
@@ -5543,7 +5543,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
dedicated_queues, "dedicated_queues");
cmdline_parse_token_num_t cmd_setbonding_lacp_dedicated_queues_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_lacp_dedicated_queues_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
mode, "enable#disable");
@@ -5611,7 +5611,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
balance_xmit_policy, "balance_xmit_policy");
cmdline_parse_token_num_t cmd_setbonding_balance_xmit_policy_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_balance_xmit_policy_policy =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
policy, "l2#l23#l34");
@@ -5759,7 +5759,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_show_bonding_config_result,
config, "config");
cmdline_parse_token_num_t cmd_showbonding_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bonding_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bonding_config = {
.f = cmd_show_bonding_config_parsed,
@@ -5812,10 +5812,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_primary_result,
primary, "primary");
cmdline_parse_token_num_t cmd_setbonding_primary_slave =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setbonding_primary_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_primary = {
.f = cmd_set_bonding_primary_parsed,
@@ -5870,10 +5870,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_add_bonding_slave_result,
slave, "slave");
cmdline_parse_token_num_t cmd_addbonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_addbonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_add_bonding_slave = {
.f = cmd_add_bonding_slave_parsed,
@@ -5928,10 +5928,10 @@ cmdline_parse_token_string_t cmd_removebonding_slave_slave =
slave, "slave");
cmdline_parse_token_num_t cmd_removebonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_removebonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_remove_bonding_slave = {
.f = cmd_remove_bonding_slave_parsed,
@@ -6005,10 +6005,10 @@ cmdline_parse_token_string_t cmd_createbonded_device_device =
device, "device");
cmdline_parse_token_num_t cmd_createbonded_device_mode =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- mode, UINT8);
+ mode, RTE_UINT8);
cmdline_parse_token_num_t cmd_createbonded_device_socket =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- socket, UINT8);
+ socket, RTE_UINT8);
cmdline_parse_inst_t cmd_create_bonded_device = {
.f = cmd_create_bonded_device_parsed,
@@ -6061,7 +6061,7 @@ cmdline_parse_token_string_t cmd_set_bond_mac_addr_mac =
"mac_addr");
cmdline_parse_token_num_t cmd_set_bond_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_bond_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_bond_mac_addr_result, address);
@@ -6114,10 +6114,10 @@ cmdline_parse_token_string_t cmd_set_bond_mon_period_mon_period =
mon_period, "mon_period");
cmdline_parse_token_num_t cmd_set_bond_mon_period_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_bond_mon_period_period_ms =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- period_ms, UINT32);
+ period_ms, RTE_UINT32);
cmdline_parse_inst_t cmd_set_bond_mon_period = {
.f = cmd_set_bond_mon_period_parsed,
@@ -6176,7 +6176,7 @@ cmdline_parse_token_string_t cmd_set_bonding_agg_mode_agg_mode =
cmdline_parse_token_num_t cmd_set_bonding_agg_mode_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_agg_mode_policy_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_bonding_agg_mode_policy_string =
TOKEN_STRING_INITIALIZER(
@@ -6364,11 +6364,11 @@ cmdline_parse_token_string_t cmd_set_burst_tx_retry_tx =
cmdline_parse_token_string_t cmd_set_burst_tx_retry_delay =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, delay, "delay");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_time =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_burst_tx_retry_retry =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry, "retry");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_retry_num =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, RTE_UINT32);
cmdline_parse_inst_t cmd_set_burst_tx_retry = {
.f = cmd_set_burst_tx_retry_parsed,
@@ -6434,7 +6434,7 @@ cmdline_parse_token_string_t cmd_setpromisc_portall =
"all");
cmdline_parse_token_num_t cmd_setpromisc_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_promisc_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setpromisc_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_promisc_mode_result, mode,
"on#off");
@@ -6514,7 +6514,7 @@ cmdline_parse_token_string_t cmd_setallmulti_portall =
"all");
cmdline_parse_token_num_t cmd_setallmulti_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_allmulti_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setallmulti_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_allmulti_mode_result, mode,
"on#off");
@@ -6592,25 +6592,25 @@ cmdline_parse_token_string_t cmd_lfc_set_high_water_str =
hw_str, "high_water");
cmdline_parse_token_num_t cmd_lfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_low_water_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
lw_str, "low_water");
cmdline_parse_token_num_t cmd_lfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_pause_time_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
pt_str, "pause_time");
cmdline_parse_token_num_t cmd_lfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_send_xon_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
xon_str, "send_xon");
cmdline_parse_token_num_t cmd_lfc_set_send_xon =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- send_xon, UINT16);
+ send_xon, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_mac_ctrl_frame_fwd_mode =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
mac_ctrl_frame_fwd, "mac_ctrl_frame_fwd");
@@ -6625,7 +6625,7 @@ cmdline_parse_token_string_t cmd_lfc_set_autoneg =
autoneg, "on#off");
cmdline_parse_token_num_t cmd_lfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
/* forward declaration */
static void
@@ -6920,19 +6920,19 @@ cmdline_parse_token_string_t cmd_pfc_set_tx_mode =
tx_pfc_mode, "on#off");
cmdline_parse_token_num_t cmd_pfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_num_t cmd_pfc_set_priority =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- priority, UINT8);
+ priority, RTE_UINT8);
cmdline_parse_token_num_t cmd_pfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_priority_flow_control_set = {
.f = cmd_priority_flow_ctrl_set_parsed,
@@ -7070,7 +7070,7 @@ cmdline_parse_token_string_t cmd_start_tx_first_n_tx_first =
tx_first, "tx_first");
cmdline_parse_token_num_t cmd_start_tx_first_n_tx_num =
TOKEN_NUM_INITIALIZER(struct cmd_start_tx_first_n_result,
- tx_num, UINT32);
+ tx_num, RTE_UINT32);
cmdline_parse_inst_t cmd_start_tx_first_n = {
.f = cmd_start_tx_first_n_parsed,
@@ -7101,7 +7101,7 @@ cmdline_parse_token_string_t cmd_set_link_up_link_up =
cmdline_parse_token_string_t cmd_set_link_up_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_up_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_up_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, RTE_UINT16);
static void cmd_set_link_up_parsed(__attribute__((unused)) void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -7140,7 +7140,7 @@ cmdline_parse_token_string_t cmd_set_link_down_link_down =
cmdline_parse_token_string_t cmd_set_link_down_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_down_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_down_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, RTE_UINT16);
static void cmd_set_link_down_parsed(
__attribute__((unused)) void *parsed_result,
@@ -7327,7 +7327,7 @@ cmdline_parse_token_string_t cmd_showport_what =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, what,
"info#summary#stats#xstats#fdir#stat_qmap#dcb_tc#cap");
cmdline_parse_token_num_t cmd_showport_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, RTE_UINT16);
cmdline_parse_inst_t cmd_showport = {
.f = cmd_showport_parsed,
@@ -7373,9 +7373,9 @@ cmdline_parse_token_string_t cmd_showqueue_type =
cmdline_parse_token_string_t cmd_showqueue_what =
TOKEN_STRING_INITIALIZER(struct cmd_showqueue_result, what, "info");
cmdline_parse_token_num_t cmd_showqueue_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, RTE_UINT16);
cmdline_parse_token_num_t cmd_showqueue_queuenum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, RTE_UINT16);
cmdline_parse_inst_t cmd_showqueue = {
.f = cmd_showqueue_parsed,
@@ -7456,9 +7456,9 @@ cmdline_parse_token_string_t cmd_read_reg_read =
cmdline_parse_token_string_t cmd_read_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_read_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, RTE_UINT32);
cmdline_parse_inst_t cmd_read_reg = {
.f = cmd_read_reg_parsed,
@@ -7501,16 +7501,16 @@ cmdline_parse_token_string_t cmd_read_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_read_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit_field = {
.f = cmd_read_reg_bit_field_parsed,
@@ -7552,11 +7552,11 @@ cmdline_parse_token_string_t cmd_read_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_read_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit = {
.f = cmd_read_reg_bit_parsed,
@@ -7595,11 +7595,11 @@ cmdline_parse_token_string_t cmd_write_reg_write =
cmdline_parse_token_string_t cmd_write_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_write_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg = {
.f = cmd_write_reg_parsed,
@@ -7644,19 +7644,19 @@ cmdline_parse_token_string_t cmd_write_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_write_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_value =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg_bit_field = {
.f = cmd_write_reg_bit_field_parsed,
@@ -7702,13 +7702,13 @@ cmdline_parse_token_string_t cmd_write_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_write_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, RTE_UINT8);
cmdline_parse_inst_t cmd_write_reg_bit = {
.f = cmd_write_reg_bit_parsed,
@@ -7754,11 +7754,11 @@ cmdline_parse_token_string_t cmd_read_rxd_txd_rxd_txd =
TOKEN_STRING_INITIALIZER(struct cmd_read_rxd_txd_result, rxd_txd,
"rxd#txd");
cmdline_parse_token_num_t cmd_read_rxd_txd_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_queue_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_desc_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, RTE_UINT16);
cmdline_parse_inst_t cmd_read_rxd_txd = {
.f = cmd_read_rxd_txd_parsed,
@@ -7836,7 +7836,7 @@ cmdline_parse_token_string_t cmd_mac_addr_what =
"add#remove#set");
cmdline_parse_token_num_t cmd_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_mac_addr_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -7882,7 +7882,7 @@ cmdline_parse_token_string_t cmd_eth_peer_set =
cmdline_parse_token_string_t cmd_eth_peer =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, eth_peer, "eth-peer");
cmdline_parse_token_num_t cmd_eth_peer_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_eth_peer_addr =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, peer_addr, NULL);
@@ -7931,13 +7931,13 @@ cmdline_parse_token_string_t cmd_setqmap_what =
what, "tx#rx");
cmdline_parse_token_num_t cmd_setqmap_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_queueid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_mapvalue =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- map_value, UINT8);
+ map_value, RTE_UINT8);
cmdline_parse_inst_t cmd_set_qmap = {
.f = cmd_set_qmap_parsed,
@@ -8033,7 +8033,7 @@ cmdline_parse_token_string_t cmd_set_uc_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_hash_table,
what, "uta");
@@ -8094,7 +8094,7 @@ cmdline_parse_token_string_t cmd_set_uc_all_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_all_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_all_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_all_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_all_hash_table,
what, "uta");
@@ -8186,13 +8186,13 @@ cmdline_parse_token_string_t cmd_set_vf_macvlan_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_macvlan_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_macvlan_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_macvlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_macvlan_vf_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_set_vf_macvlan_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_macvlan_filter,
address);
@@ -8255,13 +8255,13 @@ cmdline_parse_token_string_t cmd_setvf_traffic_port =
port, "port");
cmdline_parse_token_num_t cmd_setvf_traffic_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setvf_traffic_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
vf, "vf");
cmdline_parse_token_num_t cmd_setvf_traffic_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_setvf_traffic_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
what, "tx#rx");
@@ -8343,13 +8343,13 @@ cmdline_parse_token_string_t cmd_set_vf_rxmode_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_rxmode_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_rxmode_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_rxmode_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vf_rxmode_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
what, "rxmode");
@@ -8426,13 +8426,13 @@ cmdline_parse_token_string_t cmd_vf_mac_addr_port =
port,"port");
cmdline_parse_token_num_t cmd_vf_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_mac_addr_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_mac_addr_result,
vf,"vf");
cmdline_parse_token_num_t cmd_vf_mac_addr_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_vf_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_vf_mac_addr_result,
address);
@@ -8517,19 +8517,19 @@ cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_port =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
port, "port");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vf_mask =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vf_mask, UINT64);
+ vf_mask, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rxvlan_filter = {
.f = cmd_vf_rx_vlan_filter_parsed,
@@ -8584,19 +8584,19 @@ cmdline_parse_token_string_t cmd_queue_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_queue_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_rate_limit_queue =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
queue, "queue");
cmdline_parse_token_num_t cmd_queue_rate_limit_queuenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- queue_num, UINT8);
+ queue_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_queue_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_inst_t cmd_queue_rate_limit = {
.f = cmd_queue_rate_limit_parsed,
@@ -8654,25 +8654,25 @@ cmdline_parse_token_string_t cmd_vf_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_vf_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rate_limit_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_vf_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_vf_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_q_msk =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
q_msk, "queue_mask");
cmdline_parse_token_num_t cmd_vf_rate_limit_q_msk_val =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- q_msk_val, UINT64);
+ q_msk_val, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rate_limit = {
.f = cmd_vf_rate_limit_parsed,
@@ -8794,7 +8794,7 @@ cmdline_parse_token_string_t cmd_tunnel_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_tunnel_filter_outer_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_tunnel_filter_result,
outer_mac);
@@ -8803,7 +8803,7 @@ cmdline_parse_token_etheraddr_t cmd_tunnel_filter_inner_mac =
inner_mac);
cmdline_parse_token_num_t cmd_tunnel_filter_innner_vlan =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- inner_vlan, UINT16);
+ inner_vlan, RTE_UINT16);
cmdline_parse_token_ipaddr_t cmd_tunnel_filter_ip_value =
TOKEN_IPADDR_INITIALIZER(struct cmd_tunnel_filter_result,
ip_value);
@@ -8817,10 +8817,10 @@ cmdline_parse_token_string_t cmd_tunnel_filter_filter_type =
"imac#omac-imac-tenid");
cmdline_parse_token_num_t cmd_tunnel_filter_tenant_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- tenant_id, UINT32);
+ tenant_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_tunnel_filter_queue_num =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- queue_num, UINT16);
+ queue_num, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_filter = {
.f = cmd_tunnel_filter_parsed,
@@ -8886,10 +8886,10 @@ cmdline_parse_token_string_t cmd_tunnel_udp_config_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_udp_config_udp_port =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- udp_port, UINT16);
+ udp_port, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_udp_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_udp_config = {
.f = cmd_tunnel_udp_config_parsed,
@@ -8959,7 +8959,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_config =
"config");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port,
udp_tunnel_port,
@@ -8972,7 +8972,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
"vxlan#geneve#vxlan-gpe");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
.f = cmd_cfg_tunnel_udp_port_parsed,
@@ -9021,13 +9021,13 @@ cmdline_parse_token_string_t cmd_global_config_cmd =
"global_config");
cmdline_parse_token_num_t cmd_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_global_config_type =
TOKEN_STRING_INITIALIZER(struct cmd_global_config_result,
cfg_type, "gre-key-len");
cmdline_parse_token_num_t cmd_global_config_gre_key_len =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result,
- len, UINT8);
+ len, RTE_UINT8);
cmdline_parse_inst_t cmd_global_config = {
.f = cmd_global_config_parsed,
@@ -9064,13 +9064,13 @@ cmdline_parse_token_string_t cmd_mirror_mask_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_mask_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_mask_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_mask_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
what, "pool-mirror-up#pool-mirror-down"
@@ -9083,7 +9083,7 @@ cmdline_parse_token_string_t cmd_mirror_mask_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_mask_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
on, "on#off");
@@ -9179,13 +9179,13 @@ cmdline_parse_token_string_t cmd_mirror_link_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_link_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_link_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_link_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
what, "uplink-mirror#downlink-mirror");
@@ -9194,7 +9194,7 @@ cmdline_parse_token_string_t cmd_mirror_link_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_link_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
on, "on#off");
@@ -9265,13 +9265,13 @@ cmdline_parse_token_string_t cmd_rm_mirror_rule_port =
port, "port");
cmdline_parse_token_num_t cmd_rm_mirror_rule_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rm_mirror_rule_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_rm_mirror_rule_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_rm_mirror_rule_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
static void
cmd_reset_mirror_rule_parsed(void *parsed_result,
@@ -9464,7 +9464,7 @@ cmdline_parse_token_string_t cmd_syn_filter_filter =
filter, "syn_filter");
cmdline_parse_token_num_t cmd_syn_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_syn_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_syn_filter_result,
ops, "add#del");
@@ -9479,7 +9479,7 @@ cmdline_parse_token_string_t cmd_syn_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_syn_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_syn_filter = {
.f = cmd_syn_filter_parsed,
@@ -9556,7 +9556,7 @@ cmdline_parse_token_string_t cmd_queue_region_port =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result, port, "port");
cmdline_parse_token_num_t cmd_queue_region_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
cmd, "queue-region");
@@ -9565,19 +9565,19 @@ cmdline_parse_token_string_t cmd_queue_region_id =
region, "region_id");
cmdline_parse_token_num_t cmd_queue_region_index =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_start_index =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_start_index, "queue_start_index");
cmdline_parse_token_num_t cmd_queue_region_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_id, UINT8);
+ queue_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_num =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_num, "queue_num");
cmdline_parse_token_num_t cmd_queue_region_queue_num_value =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_num_value, UINT8);
+ queue_num_value, RTE_UINT8);
cmdline_parse_inst_t cmd_queue_region = {
.f = cmd_queue_region_parsed,
@@ -9656,7 +9656,7 @@ cmdline_parse_token_string_t cmd_region_flowtype_port =
port, "port");
cmdline_parse_token_num_t cmd_region_flowtype_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_region_flowtype_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
cmd, "queue-region");
@@ -9665,13 +9665,13 @@ cmdline_parse_token_string_t cmd_region_flowtype_index =
region, "region_id");
cmdline_parse_token_num_t cmd_region_flowtype_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_region_flowtype_flow_index =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
flowtype, "flowtype");
cmdline_parse_token_num_t cmd_region_flowtype_flow_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- flowtype_id, UINT8);
+ flowtype_id, RTE_UINT8);
cmdline_parse_inst_t cmd_region_flowtype = {
.f = cmd_region_flowtype_parsed,
.data = NULL,
@@ -9747,7 +9747,7 @@ cmdline_parse_token_string_t cmd_user_priority_region_port =
port, "port");
cmdline_parse_token_num_t cmd_user_priority_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_user_priority_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
cmd, "queue-region");
@@ -9756,13 +9756,13 @@ cmdline_parse_token_string_t cmd_user_priority_region_UP =
user_priority, "UP");
cmdline_parse_token_num_t cmd_user_priority_region_UP_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- user_priority_id, UINT8);
+ user_priority_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_user_priority_region_region =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
region, "region_id");
cmdline_parse_token_num_t cmd_user_priority_region_region_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_inst_t cmd_user_priority_region = {
.f = cmd_user_priority_region_parsed,
@@ -9840,7 +9840,7 @@ cmdline_parse_token_string_t cmd_flush_queue_region_port =
port, "port");
cmdline_parse_token_num_t cmd_flush_queue_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_flush_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flush_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_flush_queue_region_result,
cmd, "queue-region");
@@ -9921,7 +9921,7 @@ cmdline_parse_token_string_t cmd_show_queue_region_info_port =
port, "port");
cmdline_parse_token_num_t cmd_show_queue_region_info_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_show_queue_region_info,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_queue_region_info_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_show_queue_region_info,
cmd, "queue-region");
@@ -10022,7 +10022,7 @@ cmdline_parse_token_string_t cmd_2tuple_filter_filter =
filter, "2tuple_filter");
cmdline_parse_token_num_t cmd_2tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
ops, "add#del");
@@ -10031,37 +10031,37 @@ cmdline_parse_token_string_t cmd_2tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_2tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_2tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_2tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_2tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_2tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_2tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_2tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_2tuple_filter = {
.f = cmd_2tuple_filter_parsed,
@@ -10201,7 +10201,7 @@ cmdline_parse_token_string_t cmd_5tuple_filter_filter =
filter, "5tuple_filter");
cmdline_parse_token_num_t cmd_5tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
ops, "add#del");
@@ -10222,43 +10222,43 @@ cmdline_parse_token_string_t cmd_5tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_5tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_src_port =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
src_port, "src_port");
cmdline_parse_token_num_t cmd_5tuple_filter_src_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- src_port_value, UINT16);
+ src_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_5tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_5tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_5tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_5tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_5tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_5tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_5tuple_filter = {
.f = cmd_5tuple_filter_parsed,
@@ -10424,7 +10424,7 @@ cmdline_parse_token_string_t cmd_flex_filter_filter =
filter, "flex_filter");
cmdline_parse_token_num_t cmd_flex_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flex_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
ops, "add#del");
@@ -10433,7 +10433,7 @@ cmdline_parse_token_string_t cmd_flex_filter_len =
len, "len");
cmdline_parse_token_num_t cmd_flex_filter_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- len_value, UINT8);
+ len_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_bytes =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
bytes, "bytes");
@@ -10451,13 +10451,13 @@ cmdline_parse_token_string_t cmd_flex_filter_priority =
priority, "priority");
cmdline_parse_token_num_t cmd_flex_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_flex_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_flex_filter = {
.f = cmd_flex_filter_parsed,
.data = NULL,
@@ -10503,7 +10503,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_filter =
filter, "ethertype_filter");
cmdline_parse_token_num_t cmd_ethertype_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
ops, "add#del");
@@ -10518,7 +10518,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_ethertype =
ethertype, "ethertype");
cmdline_parse_token_num_t cmd_ethertype_filter_ethertype_value =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- ethertype_value, UINT16);
+ ethertype_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_drop =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
drop, "drop#fwd");
@@ -10527,7 +10527,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_ethertype_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
static void
cmd_ethertype_filter_parsed(void *parsed_result,
@@ -11003,7 +11003,7 @@ cmdline_parse_token_string_t cmd_flow_director_filter =
flow_director_filter, "flow_director_filter");
cmdline_parse_token_num_t cmd_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ops, "add#del#update");
@@ -11018,7 +11018,7 @@ cmdline_parse_token_string_t cmd_flow_director_ether =
ether, "ether");
cmdline_parse_token_num_t cmd_flow_director_ether_type =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ether_type, UINT16);
+ ether_type, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
src, "src");
@@ -11027,7 +11027,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_src =
ip_src);
cmdline_parse_token_num_t cmd_flow_director_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
dst, "dst");
@@ -11036,37 +11036,37 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_dst =
ip_dst);
cmdline_parse_token_num_t cmd_flow_director_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_verify_tag =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
verify_tag, "verify_tag");
cmdline_parse_token_num_t cmd_flow_director_verify_tag_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- verify_tag_value, UINT32);
+ verify_tag_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_tos =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
tos, "tos");
cmdline_parse_token_num_t cmd_flow_director_tos_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tos_value, UINT8);
+ tos_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_proto =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
proto, "proto");
cmdline_parse_token_num_t cmd_flow_director_proto_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- proto_value, UINT8);
+ proto_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ttl, "ttl");
cmdline_parse_token_num_t cmd_flow_director_ttl_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ttl_value, UINT8);
+ ttl_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- vlan_value, UINT16);
+ vlan_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexbytes =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
flexbytes, "flexbytes");
@@ -11084,13 +11084,13 @@ cmdline_parse_token_string_t cmd_flow_director_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_flow_director_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_fd_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
fd_id, "fd_id");
cmdline_parse_token_num_t cmd_flow_director_fd_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- fd_id_value, UINT32);
+ fd_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
@@ -11124,7 +11124,7 @@ cmdline_parse_token_string_t cmd_flow_director_tunnel_id =
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tunnel_id_value, UINT32);
+ tunnel_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_packet =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
packet, "packet");
@@ -11368,7 +11368,7 @@ cmdline_parse_token_string_t cmd_flush_flow_director_flush =
flush_flow_director, "flush_flow_director");
cmdline_parse_token_num_t cmd_flush_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flush_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_flush_flow_director_parsed(void *parsed_result,
@@ -11486,13 +11486,13 @@ cmdline_parse_token_string_t cmd_flow_director_mask =
flow_director_mask, "flow_director_mask");
cmdline_parse_token_num_t cmd_flow_director_mask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_mask_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- vlan_mask, UINT16);
+ vlan_mask, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
src_mask, "src_mask");
@@ -11504,7 +11504,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_src =
ipv6_src);
cmdline_parse_token_num_t cmd_flow_director_mask_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
dst_mask, "dst_mask");
@@ -11516,7 +11516,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_dst =
ipv6_dst);
cmdline_parse_token_num_t cmd_flow_director_mask_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
@@ -11535,19 +11535,19 @@ cmdline_parse_token_string_t cmd_flow_director_mask_mac =
mac, "mac");
cmdline_parse_token_num_t cmd_flow_director_mask_mac_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- mac_addr_byte_mask, UINT8);
+ mac_addr_byte_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_type, "tunnel-type");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_type_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_type_mask, UINT8);
+ tunnel_type_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_id_mask, UINT32);
+ tunnel_id_mask, RTE_UINT32);
cmdline_parse_inst_t cmd_set_flow_director_ip_mask = {
.f = cmd_flow_director_mask_parsed,
@@ -11701,7 +11701,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexmask =
"flow_director_flex_mask");
cmdline_parse_token_num_t cmd_flow_director_flexmask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flex_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexmask_flow =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flex_mask_result,
flow, "flow");
@@ -11819,7 +11819,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexpayload =
"flow_director_flex_payload");
cmdline_parse_token_num_t cmd_flow_director_flexpayload_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flexpayload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexpayload_payload_layer =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flexpayload_result,
payload_layer, "raw#l2#l3#l4");
@@ -11887,7 +11887,7 @@ cmdline_parse_token_string_t cmd_get_sym_hash_ena_per_port_all =
get_sym_hash_ena_per_port, "get_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_get_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_sym_hash_ena_per_port = {
.f = cmd_get_sym_hash_per_port_parsed,
@@ -11943,7 +11943,7 @@ cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_all =
set_sym_hash_ena_per_port, "set_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_set_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_enable =
TOKEN_STRING_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
enable, "enable#disable");
@@ -12065,7 +12065,7 @@ cmdline_parse_token_string_t cmd_get_hash_global_config_all =
get_hash_global_config, "get_hash_global_config");
cmdline_parse_token_num_t cmd_get_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_hash_global_config = {
.f = cmd_get_hash_global_config_parsed,
@@ -12137,7 +12137,7 @@ cmdline_parse_token_string_t cmd_set_hash_global_config_all =
set_hash_global_config, "set_hash_global_config");
cmdline_parse_token_num_t cmd_set_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_global_config_hash_func =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_global_config_result,
hash_func, "toeplitz#simple_xor#default");
@@ -12253,7 +12253,7 @@ cmdline_parse_token_string_t cmd_set_hash_input_set_cmd =
set_hash_input_set, "set_hash_input_set");
cmdline_parse_token_num_t cmd_set_hash_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_input_set_result,
flow_type, NULL);
@@ -12326,7 +12326,7 @@ cmdline_parse_token_string_t cmd_set_fdir_input_set_cmd =
set_fdir_input_set, "set_fdir_input_set");
cmdline_parse_token_num_t cmd_set_fdir_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_fdir_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_fdir_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
flow_type,
@@ -12399,7 +12399,7 @@ cmdline_parse_token_string_t cmd_mcast_addr_what =
TOKEN_STRING_INITIALIZER(struct cmd_mcast_addr_result, what,
"add#remove");
cmdline_parse_token_num_t cmd_mcast_addr_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mcast_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -12448,7 +12448,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
@@ -12464,7 +12464,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_eth_type =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_eth_type_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- eth_type_val, UINT16);
+ eth_type_val, RTE_UINT16);
static enum rte_eth_tunnel_type
str2fdir_l2_tunnel_type(char *string)
@@ -12582,7 +12582,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_en_dis_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
@@ -12760,7 +12760,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_port_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_tag_id_val, UINT32);
+ port_tag_id_val, RTE_UINT32);
cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12768,7 +12768,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_e_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- e_tag_id_val, UINT16);
+ e_tag_id_val, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12776,7 +12776,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
cmdline_parse_token_num_t cmd_config_e_tag_dst_pool_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- dst_pool_val, UINT8);
+ dst_pool_val, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_e_tag_port =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12784,7 +12784,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port =
cmdline_parse_token_num_t cmd_config_e_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_vf =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12792,7 +12792,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_vf =
cmdline_parse_token_num_t cmd_config_e_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
/* E-tag insertion configuration */
static void
@@ -13111,11 +13111,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
@@ -13217,11 +13217,11 @@ cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
@@ -13323,11 +13323,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_stripq_stripq =
cmdline_parse_token_num_t cmd_vf_vlan_stripq_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_stripq_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_vlan_stripq_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
@@ -13429,15 +13429,15 @@ cmdline_parse_token_string_t cmd_vf_vlan_insert_insert =
cmdline_parse_token_num_t cmd_vf_vlan_insert_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vlan_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
static void
cmd_set_vf_vlan_insert_parsed(
@@ -13527,7 +13527,7 @@ cmdline_parse_token_string_t cmd_tx_loopback_loopback =
cmdline_parse_token_num_t cmd_tx_loopback_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_loopback_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_loopback_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_loopback_result,
@@ -13627,7 +13627,7 @@ cmdline_parse_token_string_t cmd_all_queues_drop_en_drop =
cmdline_parse_token_num_t cmd_all_queues_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_all_queues_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_all_queues_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_all_queues_drop_en_result,
@@ -13719,11 +13719,11 @@ cmdline_parse_token_string_t cmd_vf_split_drop_en_drop =
cmdline_parse_token_num_t cmd_vf_split_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_split_drop_en_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_split_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_split_drop_en_result,
@@ -13813,11 +13813,11 @@ cmdline_parse_token_string_t cmd_set_vf_mac_addr_addr =
cmdline_parse_token_num_t cmd_set_vf_mac_addr_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_mac_addr_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_vf_mac_addr_mac_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_mac_addr_result,
mac_addr);
@@ -13914,7 +13914,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_on_offload =
cmdline_parse_token_num_t cmd_macsec_offload_on_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_on_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_on_on =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_on_result,
@@ -14026,7 +14026,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_off_offload =
cmdline_parse_token_num_t cmd_macsec_offload_off_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_off_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_off_off =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_off_result,
@@ -14118,7 +14118,7 @@ cmdline_parse_token_string_t cmd_macsec_sc_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
TOKEN_ETHERADDR_INITIALIZER
(struct cmd_macsec_sc_result,
@@ -14126,7 +14126,7 @@ cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
cmdline_parse_token_num_t cmd_macsec_sc_pi =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- pi, UINT16);
+ pi, RTE_UINT16);
static void
cmd_set_macsec_sc_parsed(
@@ -14210,19 +14210,19 @@ cmdline_parse_token_string_t cmd_macsec_sa_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_macsec_sa_idx =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- idx, UINT8);
+ idx, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_an =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- an, UINT8);
+ an, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_pn =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- pn, UINT32);
+ pn, RTE_UINT32);
cmdline_parse_token_string_t cmd_macsec_sa_key =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_sa_result,
@@ -14330,11 +14330,11 @@ cmdline_parse_token_string_t cmd_vf_promisc_promisc =
cmdline_parse_token_num_t cmd_vf_promisc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_promisc_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_promisc_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_promisc_result,
@@ -14420,11 +14420,11 @@ cmdline_parse_token_string_t cmd_vf_allmulti_allmulti =
cmdline_parse_token_num_t cmd_vf_allmulti_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_allmulti_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_allmulti_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_allmulti_result,
@@ -14510,11 +14510,11 @@ cmdline_parse_token_string_t cmd_set_vf_broadcast_broadcast =
cmdline_parse_token_num_t cmd_set_vf_broadcast_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_broadcast_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_broadcast_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_broadcast_result,
@@ -14604,11 +14604,11 @@ cmdline_parse_token_string_t cmd_set_vf_vlan_tag_tag =
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_vlan_tag_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
@@ -14714,19 +14714,19 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_max_bw =
cmdline_parse_token_num_t cmd_vf_tc_bw_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_no =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_no, UINT8);
+ tc_no, RTE_UINT8);
cmdline_parse_token_num_t cmd_vf_tc_bw_bw =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- bw, UINT32);
+ bw, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_tc_bw_result,
@@ -14734,7 +14734,7 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_map =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_map, UINT8);
+ tc_map, RTE_UINT8);
/* VF max bandwidth setting */
static void
@@ -15039,7 +15039,7 @@ cmdline_parse_token_string_t cmd_set_port_tm_hierarchy_default_default =
cmdline_parse_token_num_t cmd_set_port_tm_hierarchy_default_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_hierarchy_default_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_set_port_tm_hierarchy_default_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -15119,27 +15119,27 @@ cmdline_parse_token_string_t cmd_set_vxlan_vni =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vni");
cmdline_parse_token_num_t cmd_set_vxlan_vni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_vxlan_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-src");
cmdline_parse_token_num_t cmd_set_vxlan_udp_src_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-dst");
cmdline_parse_token_num_t cmd_set_vxlan_udp_dst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_ip_tos =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-tos");
cmdline_parse_token_num_t cmd_set_vxlan_ip_tos_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-ttl");
cmdline_parse_token_num_t cmd_set_vxlan_ip_ttl_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-src");
@@ -15154,7 +15154,7 @@ cmdline_parse_token_string_t cmd_set_vxlan_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_vxlan_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"eth-src");
@@ -15339,7 +15339,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_tni =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"tni");
cmdline_parse_token_num_t cmd_set_nvgre_tni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_nvgre_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"ip-src");
@@ -15354,7 +15354,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_nvgre_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_nvgre_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"eth-src");
@@ -15485,7 +15485,7 @@ cmdline_parse_token_string_t cmd_set_l2_encap_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_l2_encap_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_l2_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"eth-src");
@@ -15645,7 +15645,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "ip-src");
@@ -15661,7 +15661,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "eth-src");
@@ -15869,19 +15869,19 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-src");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_src_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_src,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-dst");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_dst_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_dst,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "ip-src");
@@ -15897,7 +15897,7 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "eth-src");
@@ -16140,7 +16140,7 @@ cmdline_parse_token_string_t cmd_ddp_add_ddp =
cmdline_parse_token_string_t cmd_ddp_add_add =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, add, "add");
cmdline_parse_token_num_t cmd_ddp_add_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_add_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, filepath, NULL);
@@ -16220,7 +16220,7 @@ cmdline_parse_token_string_t cmd_ddp_del_ddp =
cmdline_parse_token_string_t cmd_ddp_del_del =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
cmdline_parse_token_num_t cmd_ddp_del_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_del_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
@@ -16527,7 +16527,7 @@ cmdline_parse_token_string_t cmd_ddp_get_list_get =
cmdline_parse_token_string_t cmd_ddp_get_list_list =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_get_list_result, list, "list");
cmdline_parse_token_num_t cmd_ddp_get_list_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, RTE_UINT16);
static void
cmd_ddp_get_list_parsed(
@@ -16676,13 +16676,13 @@ cmdline_parse_token_string_t cmd_cfg_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_cfg_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_cfg_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_cfg_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_cfg_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
inset_type,
@@ -16695,7 +16695,7 @@ cmdline_parse_token_string_t cmd_cfg_input_set_field =
field, "field");
cmdline_parse_token_num_t cmd_cfg_input_set_field_idx =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- field_idx, UINT8);
+ field_idx, RTE_UINT8);
cmdline_parse_inst_t cmd_cfg_input_set = {
.f = cmd_cfg_input_set_parsed,
@@ -16777,13 +16777,13 @@ cmdline_parse_token_string_t cmd_clear_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_clear_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_clear_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_clear_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_clear_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
inset_type,
@@ -16840,11 +16840,11 @@ cmdline_parse_token_string_t cmd_show_vf_stats_stats =
cmdline_parse_token_num_t cmd_show_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_show_vf_stats_parsed(
@@ -16949,11 +16949,11 @@ cmdline_parse_token_string_t cmd_clear_vf_stats_stats =
cmdline_parse_token_num_t cmd_clear_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_clear_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_clear_vf_stats_parsed(
@@ -17033,7 +17033,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_reset_config =
cmdline_parse_token_num_t cmd_pctype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_reset_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
@@ -17115,7 +17115,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_get_port =
cmdline_parse_token_num_t cmd_pctype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_get_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_get_result,
@@ -17219,7 +17219,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_config =
cmdline_parse_token_num_t cmd_pctype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_update_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_update_result,
@@ -17239,7 +17239,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_pc_type =
cmdline_parse_token_num_t cmd_pctype_mapping_update_flow_type =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- flow_type, UINT16);
+ flow_type, RTE_UINT16);
static void
cmd_pctype_mapping_update_parsed(
@@ -17333,11 +17333,11 @@ cmdline_parse_token_string_t cmd_ptype_mapping_get_get =
cmdline_parse_token_num_t cmd_ptype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_get_valid_only =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- valid_only, UINT8);
+ valid_only, RTE_UINT8);
static void
cmd_ptype_mapping_get_parsed(
@@ -17430,19 +17430,19 @@ cmdline_parse_token_string_t cmd_ptype_mapping_replace_replace =
cmdline_parse_token_num_t cmd_ptype_mapping_replace_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_target =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- target, UINT32);
+ target, RTE_UINT32);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_mask =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- mask, UINT8);
+ mask, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_pkt_type =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- pkt_type, UINT32);
+ pkt_type, RTE_UINT32);
static void
cmd_ptype_mapping_replace_parsed(
@@ -17524,7 +17524,7 @@ cmdline_parse_token_string_t cmd_ptype_mapping_reset_reset =
cmdline_parse_token_num_t cmd_ptype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_ptype_mapping_reset_parsed(
@@ -17597,15 +17597,15 @@ cmdline_parse_token_string_t cmd_ptype_mapping_update_update =
cmdline_parse_token_num_t cmd_ptype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_update_hw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- hw_ptype, UINT8);
+ hw_ptype, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_update_sw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- sw_ptype, UINT32);
+ sw_ptype, RTE_UINT32);
static void
cmd_ptype_mapping_update_parsed(
@@ -17716,7 +17716,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_rx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_capa_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
@@ -17809,7 +17809,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_rx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_configuration_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
@@ -17887,7 +17887,7 @@ cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -18005,7 +18005,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18013,7 +18013,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18110,7 +18110,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_tx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_capa_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
@@ -18203,7 +18203,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_tx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_configuration_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
@@ -18281,7 +18281,7 @@ cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -18406,7 +18406,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18414,7 +18414,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18527,13 +18527,13 @@ cmdline_parse_token_string_t cmd_config_tx_metadata_specific_keyword =
keyword, "config");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tx_metadata_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
item, "tx_metadata");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- value, UINT32);
+ value, RTE_UINT32);
cmdline_parse_inst_t cmd_config_tx_metadata_specific = {
.f = cmd_config_tx_metadata_specific_parsed,
@@ -18582,7 +18582,7 @@ cmdline_parse_token_string_t cmd_show_tx_metadata_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_show_tx_metadata_pid =
TOKEN_NUM_INITIALIZER(struct cmd_show_tx_metadata_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_tx_metadata_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_show_tx_metadata_result,
cmd_keyword, "tx_metadata");
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..423bf6e66 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -253,7 +253,7 @@ cmdline_parse_token_string_t cmd_show_port_meter_cap_cap =
struct cmd_show_port_meter_cap_result, cap, "cap");
cmdline_parse_token_num_t cmd_show_port_meter_cap_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_cap_result, port_id, UINT16);
+ struct cmd_show_port_meter_cap_result, port_id, RTE_UINT16);
static void cmd_show_port_meter_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -359,23 +359,23 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcm_srtcm_rfc2697 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_srtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -461,27 +461,27 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_trtcm_trtcm_rfc2698 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pir, UINT64);
+ pir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pbs, UINT64);
+ pbs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -571,27 +571,27 @@ cmdline_parse_token_string_t
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_eir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- eir, UINT64);
+ eir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_rfc4115_parsed(
void *parsed_result,
@@ -672,11 +672,11 @@ cmdline_parse_token_string_t cmd_del_port_meter_profile_profile =
cmdline_parse_token_num_t cmd_del_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
static void cmd_del_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -742,13 +742,13 @@ cmdline_parse_token_string_t cmd_create_port_meter_meter =
struct cmd_create_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_create_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, port_id, UINT16);
+ struct cmd_create_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_create_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, mtr_id, UINT32);
+ struct cmd_create_port_meter_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_create_port_meter_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, profile_id, UINT32);
+ struct cmd_create_port_meter_result, profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_meter_enable =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_enable, "yes#no");
@@ -763,10 +763,10 @@ cmdline_parse_token_string_t cmd_create_port_meter_r_action =
r_action, "R#Y#G#D#r#y#g#d");
cmdline_parse_token_num_t cmd_create_port_meter_statistics_mask =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- statistics_mask, UINT64);
+ statistics_mask, RTE_UINT64);
cmdline_parse_token_num_t cmd_create_port_meter_shared =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- shared, UINT32);
+ shared, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_input_color =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_input_color, TOKEN_STRING_MULTI);
@@ -866,10 +866,10 @@ cmdline_parse_token_string_t cmd_enable_port_meter_meter =
struct cmd_enable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_enable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, port_id, UINT16);
+ struct cmd_enable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_enable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, mtr_id, UINT32);
+ struct cmd_enable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_enable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -927,10 +927,10 @@ cmdline_parse_token_string_t cmd_disable_port_meter_meter =
struct cmd_disable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_disable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, port_id, UINT16);
+ struct cmd_disable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_disable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, mtr_id, UINT32);
+ struct cmd_disable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_disable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -988,10 +988,10 @@ cmdline_parse_token_string_t cmd_del_port_meter_meter =
struct cmd_del_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_del_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, port_id, UINT16);
+ struct cmd_del_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, mtr_id, UINT32);
+ struct cmd_del_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_del_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1054,13 +1054,13 @@ cmdline_parse_token_string_t cmd_set_port_meter_profile_profile =
struct cmd_set_port_meter_profile_result, profile, "profile");
cmdline_parse_token_num_t cmd_set_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, port_id, UINT16);
+ struct cmd_set_port_meter_profile_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_profile_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_profile_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, profile_id, UINT32);
+ struct cmd_set_port_meter_profile_result, profile_id, RTE_UINT32);
static void cmd_set_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1208,15 +1208,15 @@ cmdline_parse_token_string_t cmd_set_port_meter_policer_action_action =
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_mtr_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, mtr_id,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_action_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, action_mask,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_port_meter_policer_action_policer_action =
TOKEN_STRING_INITIALIZER(
struct cmd_set_port_meter_policer_action_result,
@@ -1316,14 +1316,14 @@ cmdline_parse_token_string_t cmd_set_port_meter_stats_mask_mask =
struct cmd_set_port_meter_stats_mask_result, mask, "mask");
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, port_id, UINT16);
+ struct cmd_set_port_meter_stats_mask_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_stats_mask_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_stats_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_stats_mask_result, stats_mask,
- UINT64);
+ RTE_UINT64);
static void cmd_set_port_meter_stats_mask_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1388,10 +1388,10 @@ cmdline_parse_token_string_t cmd_show_port_meter_stats_stats =
struct cmd_show_port_meter_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_meter_stats_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, port_id, UINT16);
+ struct cmd_show_port_meter_stats_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_meter_stats_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, mtr_id, UINT32);
+ struct cmd_show_port_meter_stats_result, mtr_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_show_port_meter_stats_clear =
TOKEN_STRING_INITIALIZER(
struct cmd_show_port_meter_stats_result, clear, "yes#no");
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..c0d846422 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -217,7 +217,7 @@ cmdline_parse_token_string_t cmd_show_port_tm_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_show_port_tm_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -354,10 +354,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_level_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
static void cmd_show_port_tm_level_cap_parsed(void *parsed_result,
@@ -481,10 +481,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -593,14 +593,14 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_stats_stats =
struct cmd_show_port_tm_node_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_stats_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_clear =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_tm_node_stats_result, clear, UINT32);
+ struct cmd_show_port_tm_node_stats_result, clear, RTE_UINT32);
static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -712,11 +712,11 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_type_type =
cmdline_parse_token_num_t cmd_show_port_tm_node_type_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_type_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_type_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -804,31 +804,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_rate, UINT64);
+ cmit_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_size, UINT64);
+ cmit_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_rate, UINT64);
+ peak_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_size, UINT64);
+ peak_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_pktlen_adjust =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- pktlen_adjust, UINT32);
+ pktlen_adjust, RTE_UINT32);
static void cmd_add_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -920,11 +920,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1001,15 +1001,15 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shaper_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_add_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1101,11 +1101,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1194,11 +1194,11 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1206,19 +1206,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_g, UINT64);
+ min_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_g, UINT64);
+ max_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_g, UINT16);
+ maxp_inv_g, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_g, UINT16);
+ wq_log2_g, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1226,19 +1226,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_y, UINT64);
+ min_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_y, UINT64);
+ max_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_y, UINT16);
+ maxp_inv_y, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_y, UINT16);
+ wq_log2_y, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1246,19 +1246,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_r, UINT64);
+ min_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_r, UINT64);
+ max_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_r, UINT16);
+ maxp_inv_r, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_r, UINT16);
+ wq_log2_r, RTE_UINT16);
static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
@@ -1374,11 +1374,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
static void cmd_del_port_tm_node_wred_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1456,15 +1456,15 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_shaper_profile_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t
cmd_set_port_tm_node_shaper_shaper_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_set_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1550,31 +1550,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_nonleaf_node_node =
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_nonleaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_n_sp_priorities =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- n_sp_priorities, UINT32);
+ n_sp_priorities, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_nonleaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
@@ -1708,34 +1708,34 @@ cmdline_parse_token_string_t cmd_add_port_tm_leaf_node_node =
struct cmd_add_port_tm_leaf_node_result, node, "node");
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_cman_mode =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- cman_mode, UINT32);
+ cman_mode, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_wred_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_leaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
@@ -1858,10 +1858,10 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_node =
struct cmd_del_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_del_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_del_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1936,19 +1936,19 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_parent_parent =
struct cmd_set_port_tm_node_parent_result, parent, "parent");
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, port_id, UINT16);
+ struct cmd_set_port_tm_node_parent_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, node_id, UINT32);
+ struct cmd_set_port_tm_node_parent_result, node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_parent_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- parent_id, UINT32);
+ parent_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_priority =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_weight =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- weight, UINT32);
+ weight, RTE_UINT32);
static void cmd_set_port_tm_node_parent_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2024,10 +2024,10 @@ cmdline_parse_token_string_t cmd_suspend_port_tm_node_node =
struct cmd_suspend_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_suspend_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, port_id, UINT16);
+ struct cmd_suspend_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_suspend_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, node_id, UINT32);
+ struct cmd_suspend_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_suspend_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2089,10 +2089,10 @@ cmdline_parse_token_string_t cmd_resume_port_tm_node_node =
struct cmd_resume_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_resume_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, port_id, UINT16);
+ struct cmd_resume_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_resume_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, node_id, UINT32);
+ struct cmd_resume_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_resume_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2156,7 +2156,7 @@ cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_commit =
cmdline_parse_token_num_t cmd_port_tm_hierarchy_commit_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_port_tm_hierarchy_commit_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_clean_on_fail =
TOKEN_STRING_INITIALIZER(struct cmd_port_tm_hierarchy_commit_result,
clean_on_fail, "yes#no");
@@ -2236,17 +2236,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_ecn_ip_ecn =
ip_ecn, "ip_ecn");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_ecn_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2323,17 +2323,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_dscp_ip_dscp =
ip_dscp, "ip_dscp");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_dscp_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2410,17 +2410,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_vlan_dei_vlan_dei =
vlan_dei, "vlan_dei");
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_vlan_dei_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
diff --git a/app/test/test_cmdline_num.c b/app/test/test_cmdline_num.c
index 4c97caf3d..71a6a7fa8 100644
--- a/app/test/test_cmdline_num.c
+++ b/app/test/test_cmdline_num.c
@@ -233,31 +233,31 @@ static int
can_parse_unsigned(uint64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX)
return 0;
break;
- case INT64:
+ case RTE_INT64:
if (expected_result > INT64_MAX)
return 0;
break;
@@ -271,31 +271,31 @@ static int
can_parse_signed(int64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX || expected_result < 0)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX || expected_result < 0)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX || expected_result < 0)
return 0;
break;
- case UINT64:
+ case RTE_UINT64:
if (expected_result < 0)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX || expected_result < INT8_MIN)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX || expected_result < INT16_MIN)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX || expected_result < INT32_MIN)
return 0;
break;
@@ -315,7 +315,7 @@ test_parse_num_invalid_param(void)
int ret = 0;
/* set up a token */
- token.num_data.type = UINT32;
+ token.num_data.type = RTE_UINT32;
/* copy string to buffer */
strlcpy(buf, num_valid_positive_strs[0].str, sizeof(buf));
@@ -388,7 +388,7 @@ test_parse_num_invalid_data(void)
cmdline_parse_token_num_t token;
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test full strings */
@@ -427,7 +427,7 @@ test_parse_num_valid(void)
/** valid strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive strings */
@@ -481,13 +481,13 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
result = (int8_t) result;
break;
- case INT16:
+ case RTE_INT16:
result = (int16_t) result;
break;
- case INT32:
+ case RTE_INT32:
result = (int32_t) result;
break;
default:
@@ -505,7 +505,7 @@ test_parse_num_valid(void)
/** garbage strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive garbage strings */
@@ -559,15 +559,15 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
if (result & (INT8_MAX + 1))
result |= 0xFFFFFFFFFFFFFF00ULL;
break;
- case INT16:
+ case RTE_INT16:
if (result & (INT16_MAX + 1))
result |= 0xFFFFFFFFFFFF0000ULL;
break;
- case INT32:
+ case RTE_INT32:
if (result & (INT32_MAX + 1ULL))
result |= 0xFFFFFFFF00000000ULL;
break;
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c..d660f441a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -192,6 +192,10 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* cmdline: the numeric types to be used when defining cmdline parameters
+ have been renamed to have an ``RTE_`` prefix. For example, ``UINT8`` now
+ becomes ``RTE_UINT8``.
+
ABI Changes
-----------
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index a4e64b354..22f293904 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -70,7 +70,7 @@ cmdline_parse_token_string_t pcmd_rxmode_token_cmd =
cmdline_parse_token_string_t pcmd_portstats_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "portstats");
cmdline_parse_token_num_t pcmd_int_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, RTE_UINT16);
/* Commands taking port id and string */
cmdline_parse_token_string_t pcmd_eeprom_token_cmd =
@@ -84,7 +84,7 @@ cmdline_parse_token_string_t pcmd_regs_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "regs");
cmdline_parse_token_num_t pcmd_intstr_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_intstr_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, opt, NULL);
@@ -92,7 +92,7 @@ cmdline_parse_token_string_t pcmd_intstr_token_opt =
cmdline_parse_token_string_t pcmd_macaddr_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intmac_params, cmd, "macaddr");
cmdline_parse_token_num_t pcmd_intmac_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, RTE_UINT16);
cmdline_parse_token_etheraddr_t pcmd_intmac_token_mac =
TOKEN_ETHERADDR_INITIALIZER(struct pcmd_intmac_params, mac);
@@ -106,18 +106,18 @@ cmdline_parse_token_string_t pcmd_ringparam_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intintint_params, cmd,
"ringparam");
cmdline_parse_token_num_t pcmd_intintint_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_tx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_rx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, RTE_UINT16);
/* Pause commands */
cmdline_parse_token_string_t pcmd_pause_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "pause");
cmdline_parse_token_num_t pcmd_pause_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_pause_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params,
opt, "all#tx#rx#none");
@@ -126,11 +126,11 @@ cmdline_parse_token_string_t pcmd_pause_token_opt =
cmdline_parse_token_string_t pcmd_vlan_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, cmd, "vlan");
cmdline_parse_token_num_t pcmd_vlan_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_vlan_token_mode =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, mode, "add#del");
cmdline_parse_token_num_t pcmd_vlan_token_vid =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, RTE_UINT16);
static void
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index b0a8ee23b..523b46d6b 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -516,7 +516,7 @@ cmdline_parse_token_string_t cfg_add_neigh_start =
cmdline_parse_token_string_t cfg_add_neigh_pstr =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, pstr, "port");
cmdline_parse_token_num_t cfg_add_neigh_port =
- TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, RTE_UINT16);
cmdline_parse_token_string_t cfg_add_neigh_mac =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, mac, NULL);
diff --git a/examples/qos_sched/cmdline.c b/examples/qos_sched/cmdline.c
index 15f51830c..b163b6f9f 100644
--- a/examples/qos_sched/cmdline.c
+++ b/examples/qos_sched/cmdline.c
@@ -113,7 +113,7 @@ cmdline_parse_token_string_t cmd_setqavg_param_string =
"period#n");
cmdline_parse_token_num_t cmd_setqavg_number =
TOKEN_NUM_INITIALIZER(struct cmd_setqavg_result, number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_setqavg = {
.f = cmd_setqavg_parsed,
@@ -188,10 +188,10 @@ cmdline_parse_token_string_t cmd_subportstats_subport_string =
"subport");
cmdline_parse_token_num_t cmd_subportstats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_subportstats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_subportstats = {
.f = cmd_subportstats_parsed,
@@ -236,19 +236,19 @@ cmdline_parse_token_string_t cmd_pipestats_port_string =
"port");
cmdline_parse_token_num_t cmd_pipestats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_pipestats_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_pipestats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_pipestats_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_pipestats_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_pipestats = {
.f = cmd_pipestats_parsed,
@@ -299,31 +299,31 @@ cmdline_parse_token_string_t cmd_avg_q_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_q_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_q_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_q_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_q_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_q_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_string_t cmd_avg_q_q_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, q_string,
"q");
cmdline_parse_token_num_t cmd_avg_q_q_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, q_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_q = {
.f = cmd_avg_q_parsed,
@@ -376,25 +376,25 @@ cmdline_parse_token_string_t cmd_avg_tcpipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcpipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcpipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcpipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_tcpipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcpipe_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcpipe = {
.f = cmd_avg_tcpipe_parsed,
@@ -443,19 +443,19 @@ cmdline_parse_token_string_t cmd_avg_pipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_pipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_pipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_pipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_pipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_pipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_pipe = {
.f = cmd_avg_pipe_parsed,
@@ -502,19 +502,19 @@ cmdline_parse_token_string_t cmd_avg_tcsubport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcsubport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcsubport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcsubport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcsubport_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcsubport_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcsubport = {
.f = cmd_avg_tcsubport_parsed,
@@ -559,13 +559,13 @@ cmdline_parse_token_string_t cmd_avg_subport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_subport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_subport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_subport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_subport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_subport = {
.f = cmd_avg_subport_parsed,
diff --git a/examples/quota_watermark/qwctl/commands.c b/examples/quota_watermark/qwctl/commands.c
index a1c646b9f..3f0cef7f1 100644
--- a/examples/quota_watermark/qwctl/commands.c
+++ b/examples/quota_watermark/qwctl/commands.c
@@ -74,7 +74,7 @@ cmdline_parse_token_string_t cmd_set_variable =
TOKEN_STRING_INITIALIZER(struct cmd_set_tokens, variable, NULL);
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, RTE_UINT32);
static void
cmd_set_handler(__attribute__((unused)) void *parsed_result,
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 2d9e7689a..82e1a0a03 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -160,7 +160,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_string_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- lcore_id, UINT8);
+ lcore_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/examples/vm_power_manager/vm_power_cli.c b/examples/vm_power_manager/vm_power_cli.c
index 41e89ff20..98e61a4ac 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -155,10 +155,10 @@ cmdline_parse_token_string_t cmd_set_pcpu_vm_name =
vm_name, NULL);
cmdline_parse_token_num_t set_pcpu_vcpu =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- vcpu, UINT8);
+ vcpu, RTE_UINT8);
cmdline_parse_token_num_t set_pcpu_core =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- core, UINT64);
+ core, RTE_UINT64);
cmdline_parse_inst_t cmd_set_pcpu_set = {
@@ -408,7 +408,7 @@ cmdline_parse_token_string_t cmd_show_cpu_freq =
cmdline_parse_token_num_t cmd_show_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_show_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_inst_t cmd_show_cpu_freq_set = {
.f = cmd_show_cpu_freq_parsed,
@@ -457,7 +457,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_num_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/lib/librte_cmdline/cmdline_parse_num.c b/lib/librte_cmdline/cmdline_parse_num.c
index 182ac12f0..37d094893 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -69,23 +69,23 @@ static int
check_res_size(struct cmdline_token_num_data *nd, unsigned ressize)
{
switch (nd->type) {
- case INT8:
- case UINT8:
+ case RTE_INT8:
+ case RTE_UINT8:
if (ressize < sizeof(int8_t))
return -1;
break;
- case INT16:
- case UINT16:
+ case RTE_INT16:
+ case RTE_UINT16:
if (ressize < sizeof(int16_t))
return -1;
break;
- case INT32:
- case UINT32:
+ case RTE_INT32:
+ case RTE_UINT32:
if (ressize < sizeof(int32_t))
return -1;
break;
- case INT64:
- case UINT64:
+ case RTE_INT64:
+ case RTE_UINT64:
if (ressize < sizeof(int64_t))
return -1;
break;
@@ -259,35 +259,35 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
case HEX_OK:
case OCTAL_OK:
case BIN_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX ) {
if (res) *(int8_t *)res = (int8_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= INT16_MAX ) {
+ else if ( nd.type == RTE_INT16 && res1 <= INT16_MAX ) {
if (res) *(int16_t *)res = (int16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= INT32_MAX ) {
+ else if ( nd.type == RTE_INT32 && res1 <= INT32_MAX ) {
if (res) *(int32_t *)res = (int32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= INT64_MAX ) {
+ else if ( nd.type == RTE_INT64 && res1 <= INT64_MAX ) {
if (res) *(int64_t *)res = (int64_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT8 && res1 <= UINT8_MAX ) {
+ else if ( nd.type == RTE_UINT8 && res1 <= UINT8_MAX ) {
if (res) *(uint8_t *)res = (uint8_t) res1;
return buf-srcbuf;
}
- else if (nd.type == UINT16 && res1 <= UINT16_MAX ) {
+ else if (nd.type == RTE_UINT16 && res1 <= UINT16_MAX ) {
if (res) *(uint16_t *)res = (uint16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT32 && res1 <= UINT32_MAX ) {
+ else if ( nd.type == RTE_UINT32 && res1 <= UINT32_MAX ) {
if (res) *(uint32_t *)res = (uint32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT64 ) {
+ else if ( nd.type == RTE_UINT64 ) {
if (res) *(uint64_t *)res = res1;
return buf-srcbuf;
}
@@ -297,19 +297,19 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
break;
case DEC_NEG_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX + 1 ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX + 1 ) {
if (res) *(int8_t *)res = (int8_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
+ else if ( nd.type == RTE_INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
if (res) *(int16_t *)res = (int16_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
+ else if ( nd.type == RTE_INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
if (res) *(int32_t *)res = (int32_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
+ else if ( nd.type == RTE_INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
if (res) *(int64_t *)res = (int64_t) (-res1);
return buf-srcbuf;
}
diff --git a/lib/librte_cmdline/cmdline_parse_num.h b/lib/librte_cmdline/cmdline_parse_num.h
index 58b28cad7..02133bb21 100644
--- a/lib/librte_cmdline/cmdline_parse_num.h
+++ b/lib/librte_cmdline/cmdline_parse_num.h
@@ -14,14 +14,14 @@ extern "C" {
#endif
enum cmdline_numtype {
- UINT8 = 0,
- UINT16,
- UINT32,
- UINT64,
- INT8,
- INT16,
- INT32,
- INT64
+ RTE_UINT8 = 0,
+ RTE_UINT16,
+ RTE_UINT32,
+ RTE_UINT64,
+ RTE_INT8,
+ RTE_INT16,
+ RTE_INT32,
+ RTE_INT64
};
struct cmdline_token_num_data {
--
2.20.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums
@ 2019-04-11 10:41 1% Bruce Richardson
2019-04-11 10:41 1% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-11 10:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The cmdline defined an enum for the various numeric type parameters,
but these were missing the RTE_ prefix and so could conflict with defines
in various environments, e.g. on Windows. Adding the prefix fixes these
conflicts.
Note: this changes the API used by apps using cmdline, but since enum
values aren't changing, it's ABI compatible.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test-cmdline/commands.c | 2 +-
app/test-pmd/bpf_cmd.c | 8 +-
app/test-pmd/cmdline.c | 656 +++++++++---------
app/test-pmd/cmdline_mtr.c | 84 +--
app/test-pmd/cmdline_tm.c | 172 ++---
app/test/test_cmdline_num.c | 48 +-
doc/guides/rel_notes/release_19_05.rst | 4 +
examples/ethtool/ethtool-app/ethapp.c | 18 +-
examples/ipsec-secgw/parser.c | 2 +-
examples/qos_sched/cmdline.c | 46 +-
examples/quota_watermark/qwctl/commands.c | 2 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/vm_power_cli.c | 8 +-
lib/librte_cmdline/cmdline_parse_num.c | 40 +-
lib/librte_cmdline/cmdline_parse_num.h | 16 +-
15 files changed, 556 insertions(+), 552 deletions(-)
diff --git a/app/test-cmdline/commands.c b/app/test-cmdline/commands.c
index d81da9665..0e2ca8ac4 100644
--- a/app/test-cmdline/commands.c
+++ b/app/test-cmdline/commands.c
@@ -191,7 +191,7 @@ cmd_num_parsed(void *parsed_result,
}
cmdline_parse_token_num_t cmd_num_tok =
- TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_num_result, num, RTE_UINT32);
cmdline_parse_inst_t cmd_num = {
.f = cmd_num_parsed, /* function to call */
diff --git a/app/test-pmd/bpf_cmd.c b/app/test-pmd/bpf_cmd.c
index 830bfc13a..254290f30 100644
--- a/app/test-pmd/bpf_cmd.c
+++ b/app/test-pmd/bpf_cmd.c
@@ -124,9 +124,9 @@ cmdline_parse_token_string_t cmd_load_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_load_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_load_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_ld_result, queue, RTE_UINT16);
cmdline_parse_token_string_t cmd_load_bpf_flags =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_ld_result,
flags, NULL);
@@ -180,9 +180,9 @@ cmdline_parse_token_string_t cmd_unload_bpf_dir =
TOKEN_STRING_INITIALIZER(struct cmd_bpf_unld_result,
dir, "rx#tx");
cmdline_parse_token_num_t cmd_unload_bpf_port =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, port, RTE_UINT8);
cmdline_parse_token_num_t cmd_unload_bpf_queue =
- TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_bpf_unld_result, queue, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_bpf_unld_parse = {
.f = cmd_operate_bpf_unld_parsed,
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2ab03c111..82e67ab92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1250,7 +1250,7 @@ cmdline_parse_token_string_t cmd_operate_specific_port_port =
name, "start#stop#close#reset");
cmdline_parse_token_num_t cmd_operate_specific_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_inst_t cmd_operate_specific_port = {
.f = cmd_operate_specific_port_parsed,
@@ -1386,7 +1386,7 @@ cmdline_parse_token_string_t cmd_operate_detach_port_keyword =
keyword, "detach");
cmdline_parse_token_num_t cmd_operate_detach_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_operate_detach_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_operate_detach_port = {
.f = cmd_operate_detach_port_parsed,
@@ -1567,7 +1567,7 @@ cmdline_parse_token_string_t cmd_config_speed_specific_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, keyword,
"config");
cmdline_parse_token_num_t cmd_config_speed_specific_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_speed_specific, id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_speed_specific_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item1,
"speed");
@@ -1639,7 +1639,7 @@ cmdline_parse_token_string_t cmd_config_loopback_all_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_all, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_all_mode =
- TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_all, mode, RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_all = {
.f = cmd_config_loopback_all_parsed,
@@ -1693,13 +1693,13 @@ cmdline_parse_token_string_t cmd_config_loopback_specific_keyword =
"config");
cmdline_parse_token_num_t cmd_config_loopback_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_loopback_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_loopback_specific, item,
"loopback");
cmdline_parse_token_num_t cmd_config_loopback_specific_mode =
TOKEN_NUM_INITIALIZER(struct cmd_config_loopback_specific, mode,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_loopback_specific = {
.f = cmd_config_loopback_specific_parsed,
@@ -1789,7 +1789,7 @@ cmdline_parse_token_string_t cmd_config_rx_tx_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rx_tx, name,
"rxq#txq#rxd#txd");
cmdline_parse_token_num_t cmd_config_rx_tx_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rx_tx, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rx_tx = {
.f = cmd_config_rx_tx_parsed,
@@ -1871,7 +1871,7 @@ cmdline_parse_token_string_t cmd_config_max_pkt_len_name =
"max-pkt-len");
cmdline_parse_token_num_t cmd_config_max_pkt_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_max_pkt_len_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_config_max_pkt_len = {
.f = cmd_config_max_pkt_len_parsed,
@@ -1920,9 +1920,9 @@ cmdline_parse_token_string_t cmd_config_mtu_mtu =
TOKEN_STRING_INITIALIZER(struct cmd_config_mtu_result, keyword,
"mtu");
cmdline_parse_token_num_t cmd_config_mtu_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_config_mtu_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_mtu_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_mtu = {
.f = cmd_config_mtu_parsed,
@@ -2287,7 +2287,7 @@ cmdline_parse_token_string_t cmd_config_rss_hash_key_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key, config,
"config");
cmdline_parse_token_num_t cmd_config_rss_hash_key_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_hash_key, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_hash_key_rss_hash_key =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key,
rss_hash_key, "rss-hash-key");
@@ -2385,19 +2385,19 @@ cmdline_parse_token_string_t cmd_config_rxtx_ring_size_config =
config, "config");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_portid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- portid, UINT16);
+ portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_ring_size_rsize =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_ring_size,
rsize, "ring_size");
cmdline_parse_token_num_t cmd_config_rxtx_ring_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_ring_size,
- size, UINT16);
+ size, RTE_UINT16);
cmdline_parse_inst_t cmd_config_rxtx_ring_size = {
.f = cmd_config_rxtx_ring_size_parsed,
@@ -2486,11 +2486,11 @@ cmd_config_rxtx_queue_parsed(void *parsed_result,
cmdline_parse_token_string_t cmd_config_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_config_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_rxtx_queue, opname,
"start#stop");
@@ -2566,13 +2566,13 @@ cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_port =
port, "port");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_config_deferred_start_rxtx_queue_qid =
TOKEN_NUM_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
- qid, UINT16);
+ qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_deferred_start_rxtx_queue_opname =
TOKEN_STRING_INITIALIZER(struct cmd_config_deferred_start_rxtx_queue,
opname, "deferred_start");
@@ -2608,11 +2608,11 @@ struct cmd_setup_rxtx_queue {
cmdline_parse_token_string_t cmd_setup_rxtx_queue_port =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, port, "port");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_portid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, portid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_rxtxq =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, rxtxq, "rxq#txq");
cmdline_parse_token_num_t cmd_setup_rxtx_queue_qid =
- TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_setup_rxtx_queue, qid, RTE_UINT16);
cmdline_parse_token_string_t cmd_setup_rxtx_queue_setup =
TOKEN_STRING_INITIALIZER(struct cmd_setup_rxtx_queue, setup, "setup");
@@ -2819,7 +2819,7 @@ cmdline_parse_token_string_t cmd_config_rss_reta_port =
cmdline_parse_token_string_t cmd_config_rss_reta_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, keyword, "config");
cmdline_parse_token_num_t cmd_config_rss_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_rss_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_rss_reta_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_reta, name, "rss");
cmdline_parse_token_string_t cmd_config_rss_reta_list_name =
@@ -2927,13 +2927,13 @@ cmdline_parse_token_string_t cmd_showport_reta_show =
cmdline_parse_token_string_t cmd_showport_reta_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, port, "port");
cmdline_parse_token_num_t cmd_showport_reta_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_rss =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, rss, "rss");
cmdline_parse_token_string_t cmd_showport_reta_reta =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta, reta, "reta");
cmdline_parse_token_num_t cmd_showport_reta_size =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_reta, size, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_reta_list_of_items =
TOKEN_STRING_INITIALIZER(struct cmd_showport_reta,
list_of_items, NULL);
@@ -2978,7 +2978,7 @@ cmdline_parse_token_string_t cmd_showport_rss_hash_show =
cmdline_parse_token_string_t cmd_showport_rss_hash_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, port, "port");
cmdline_parse_token_num_t cmd_showport_rss_hash_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_rss_hash, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_showport_rss_hash_rss_hash =
TOKEN_STRING_INITIALIZER(struct cmd_showport_rss_hash, rss_hash,
"rss-hash");
@@ -3082,7 +3082,7 @@ cmdline_parse_token_string_t cmd_config_dcb_port =
cmdline_parse_token_string_t cmd_config_dcb_config =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, config, "config");
cmdline_parse_token_num_t cmd_config_dcb_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_dcb_dcb =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, dcb, "dcb");
cmdline_parse_token_string_t cmd_config_dcb_vt =
@@ -3090,7 +3090,7 @@ cmdline_parse_token_string_t cmd_config_dcb_vt =
cmdline_parse_token_string_t cmd_config_dcb_vt_en =
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, vt_en, "on#off");
cmdline_parse_token_num_t cmd_config_dcb_num_tcs =
- TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_dcb, num_tcs, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_dcb_pfc=
TOKEN_STRING_INITIALIZER(struct cmd_config_dcb, pfc, "pfc");
cmdline_parse_token_string_t cmd_config_dcb_pfc_en =
@@ -3185,7 +3185,7 @@ cmdline_parse_token_string_t cmd_config_burst_all =
cmdline_parse_token_string_t cmd_config_burst_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_burst, name, "burst");
cmdline_parse_token_num_t cmd_config_burst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_burst, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_burst = {
.f = cmd_config_burst_parsed,
@@ -3254,7 +3254,7 @@ cmdline_parse_token_string_t cmd_config_thresh_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_thresh, name,
"txpt#txht#txwt#rxpt#rxht#rxwt");
cmdline_parse_token_num_t cmd_config_thresh_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_thresh, value, RTE_UINT8);
cmdline_parse_inst_t cmd_config_thresh = {
.f = cmd_config_thresh_parsed,
@@ -3318,7 +3318,7 @@ cmdline_parse_token_string_t cmd_config_threshold_name =
TOKEN_STRING_INITIALIZER(struct cmd_config_threshold, name,
"txfreet#txrst#rxfreet");
cmdline_parse_token_num_t cmd_config_threshold_value =
- TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_config_threshold, value, RTE_UINT16);
cmdline_parse_inst_t cmd_config_threshold = {
.f = cmd_config_threshold_parsed,
@@ -3524,7 +3524,7 @@ cmdline_parse_token_string_t cmd_setmask_mask =
TOKEN_STRING_INITIALIZER(struct cmd_setmask_result, mask,
"coremask#portmask");
cmdline_parse_token_num_t cmd_setmask_value =
- TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, UINT64);
+ TOKEN_NUM_INITIALIZER(struct cmd_setmask_result, hexavalue, RTE_UINT64);
cmdline_parse_inst_t cmd_set_fwd_mask = {
.f = cmd_set_mask_parsed,
@@ -3570,7 +3570,7 @@ cmdline_parse_token_string_t cmd_set_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, what,
"nbport#nbcore#burst#verbose");
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_result, value, RTE_UINT16);
cmdline_parse_inst_t cmd_set_numbers = {
.f = cmd_set_parsed,
@@ -3618,7 +3618,7 @@ cmdline_parse_token_string_t cmd_set_log_log =
cmdline_parse_token_string_t cmd_set_log_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_log_result, type, NULL);
cmdline_parse_token_num_t cmd_set_log_level =
- TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_log_result, level, RTE_UINT32);
cmdline_parse_inst_t cmd_set_log = {
.f = cmd_set_log_parsed,
@@ -3752,7 +3752,7 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_all_all =
all, "all");
cmdline_parse_token_num_t cmd_rx_vlan_filter_all_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_all_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter_all = {
.f = cmd_rx_vlan_filter_all_parsed,
@@ -3914,10 +3914,10 @@ cmdline_parse_token_string_t cmd_vlan_tpid_what =
what, "tpid");
cmdline_parse_token_num_t cmd_vlan_tpid_tpid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- tp_id, UINT16);
+ tp_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vlan_tpid_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vlan_tpid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_vlan_tpid = {
.f = cmd_vlan_tpid_parsed,
@@ -3964,10 +3964,10 @@ cmdline_parse_token_string_t cmd_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rx_vlan_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_rx_vlan_filter = {
.f = cmd_rx_vlan_filter_parsed,
@@ -4017,10 +4017,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set = {
.f = cmd_tx_vlan_set_parsed,
@@ -4071,13 +4071,13 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_qinq_set =
set, "set");
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_qinq_vlanid_outer =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_qinq_result,
- vlan_id_outer, UINT16);
+ vlan_id_outer, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_set_qinq = {
.f = cmd_tx_vlan_set_qinq_parsed,
@@ -4129,10 +4129,10 @@ cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_pvid =
pvid, "pvid");
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_tx_vlan_set_pvid_vlan_id =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_vlan_set_pvid_mode =
TOKEN_STRING_INITIALIZER(struct cmd_tx_vlan_set_pvid_result,
mode, "on#off");
@@ -4184,7 +4184,7 @@ cmdline_parse_token_string_t cmd_tx_vlan_reset_reset =
reset, "reset");
cmdline_parse_token_num_t cmd_tx_vlan_reset_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tx_vlan_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tx_vlan_reset = {
.f = cmd_tx_vlan_reset_parsed,
@@ -4370,7 +4370,7 @@ cmdline_parse_token_string_t cmd_csum_hwsw =
hwsw, "hw#sw");
cmdline_parse_token_num_t cmd_csum_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_set = {
.f = cmd_csum_parsed,
@@ -4441,7 +4441,7 @@ cmdline_parse_token_string_t cmd_csum_tunnel_onoff =
onoff, "on#off");
cmdline_parse_token_num_t cmd_csum_tunnel_portid =
TOKEN_NUM_INITIALIZER(struct cmd_csum_tunnel_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_csum_tunnel = {
.f = cmd_csum_tunnel_parsed,
@@ -4521,10 +4521,10 @@ cmdline_parse_token_string_t cmd_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tso_set = {
.f = cmd_tso_set_parsed,
@@ -4667,10 +4667,10 @@ cmdline_parse_token_string_t cmd_tunnel_tso_set_mode =
mode, "set");
cmdline_parse_token_num_t cmd_tunnel_tso_set_tso_segsz =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- tso_segsz, UINT16);
+ tso_segsz, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_tso_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_tso_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_tso_set = {
.f = cmd_tunnel_tso_set_parsed,
@@ -4734,7 +4734,7 @@ cmdline_parse_token_string_t cmd_gro_enable_port =
cmd_keyword, "port");
cmdline_parse_token_num_t cmd_gro_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_enable_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_enable_result,
cmd_keyword, "gro");
@@ -4784,7 +4784,7 @@ cmdline_parse_token_string_t cmd_gro_show_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_gro_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gro_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_gro_show_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_gro_show_result,
cmd_keyword, "gro");
@@ -4834,7 +4834,7 @@ cmdline_parse_token_string_t cmd_gro_flush_flush =
cmd_flush, "flush");
cmdline_parse_token_num_t cmd_gro_flush_cycles =
TOKEN_NUM_INITIALIZER(struct cmd_gro_flush_result,
- cmd_cycles, UINT8);
+ cmd_cycles, RTE_UINT8);
cmdline_parse_inst_t cmd_gro_flush = {
.f = cmd_gro_flush_parsed,
@@ -4884,7 +4884,7 @@ cmdline_parse_token_string_t cmd_gso_enable_mode =
cmd_mode, "on#off");
cmdline_parse_token_num_t cmd_gso_enable_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_enable_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_enable = {
.f = cmd_gso_enable_parsed,
@@ -4943,7 +4943,7 @@ cmdline_parse_token_string_t cmd_gso_size_segsz =
cmd_segsz, "segsz");
cmdline_parse_token_num_t cmd_gso_size_size =
TOKEN_NUM_INITIALIZER(struct cmd_gso_size_result,
- cmd_size, UINT16);
+ cmd_size, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_size = {
.f = cmd_gso_size_parsed,
@@ -5001,7 +5001,7 @@ cmdline_parse_token_string_t cmd_gso_show_keyword =
cmd_keyword, "gso");
cmdline_parse_token_num_t cmd_gso_show_pid =
TOKEN_NUM_INITIALIZER(struct cmd_gso_show_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_inst_t cmd_gso_show = {
.f = cmd_gso_show_parsed,
@@ -5144,7 +5144,7 @@ cmdline_parse_token_string_t cmd_setbypass_mode_value =
value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_mode = {
.f = cmd_set_bypass_mode_parsed,
@@ -5250,7 +5250,7 @@ cmdline_parse_token_string_t cmd_setbypass_event_mode_value =
mode_value, "normal#bypass#isolate");
cmdline_parse_token_num_t cmd_setbypass_event_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bypass_event_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bypass_event = {
.f = cmd_set_bypass_event_parsed,
@@ -5417,7 +5417,7 @@ cmdline_parse_token_string_t cmd_showbypass_config_config =
config, "config");
cmdline_parse_token_num_t cmd_showbypass_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bypass_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bypass_config = {
.f = cmd_show_bypass_config_parsed,
@@ -5466,10 +5466,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
mode, "mode");
cmdline_parse_token_num_t cmd_setbonding_mode_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- value, UINT8);
+ value, RTE_UINT8);
cmdline_parse_token_num_t cmd_setbonding_mode_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_mode = {
.f = cmd_set_bonding_mode_parsed,
@@ -5543,7 +5543,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
dedicated_queues, "dedicated_queues");
cmdline_parse_token_num_t cmd_setbonding_lacp_dedicated_queues_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_lacp_dedicated_queues_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_lacp_dedicated_queues_result,
mode, "enable#disable");
@@ -5611,7 +5611,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
balance_xmit_policy, "balance_xmit_policy");
cmdline_parse_token_num_t cmd_setbonding_balance_xmit_policy_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setbonding_balance_xmit_policy_policy =
TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_balance_xmit_policy_result,
policy, "l2#l23#l34");
@@ -5759,7 +5759,7 @@ TOKEN_STRING_INITIALIZER(struct cmd_show_bonding_config_result,
config, "config");
cmdline_parse_token_num_t cmd_showbonding_config_port =
TOKEN_NUM_INITIALIZER(struct cmd_show_bonding_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_show_bonding_config = {
.f = cmd_show_bonding_config_parsed,
@@ -5812,10 +5812,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_primary_result,
primary, "primary");
cmdline_parse_token_num_t cmd_setbonding_primary_slave =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setbonding_primary_port =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_primary_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_set_bonding_primary = {
.f = cmd_set_bonding_primary_parsed,
@@ -5870,10 +5870,10 @@ TOKEN_STRING_INITIALIZER(struct cmd_add_bonding_slave_result,
slave, "slave");
cmdline_parse_token_num_t cmd_addbonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_addbonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_add_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_add_bonding_slave = {
.f = cmd_add_bonding_slave_parsed,
@@ -5928,10 +5928,10 @@ cmdline_parse_token_string_t cmd_removebonding_slave_slave =
slave, "slave");
cmdline_parse_token_num_t cmd_removebonding_slave_slaveid =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- slave_id, UINT16);
+ slave_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_removebonding_slave_port =
TOKEN_NUM_INITIALIZER(struct cmd_remove_bonding_slave_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_remove_bonding_slave = {
.f = cmd_remove_bonding_slave_parsed,
@@ -6005,10 +6005,10 @@ cmdline_parse_token_string_t cmd_createbonded_device_device =
device, "device");
cmdline_parse_token_num_t cmd_createbonded_device_mode =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- mode, UINT8);
+ mode, RTE_UINT8);
cmdline_parse_token_num_t cmd_createbonded_device_socket =
TOKEN_NUM_INITIALIZER(struct cmd_create_bonded_device_result,
- socket, UINT8);
+ socket, RTE_UINT8);
cmdline_parse_inst_t cmd_create_bonded_device = {
.f = cmd_create_bonded_device_parsed,
@@ -6061,7 +6061,7 @@ cmdline_parse_token_string_t cmd_set_bond_mac_addr_mac =
"mac_addr");
cmdline_parse_token_num_t cmd_set_bond_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_bond_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_bond_mac_addr_result, address);
@@ -6114,10 +6114,10 @@ cmdline_parse_token_string_t cmd_set_bond_mon_period_mon_period =
mon_period, "mon_period");
cmdline_parse_token_num_t cmd_set_bond_mon_period_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_bond_mon_period_period_ms =
TOKEN_NUM_INITIALIZER(struct cmd_set_bond_mon_period_result,
- period_ms, UINT32);
+ period_ms, RTE_UINT32);
cmdline_parse_inst_t cmd_set_bond_mon_period = {
.f = cmd_set_bond_mon_period_parsed,
@@ -6176,7 +6176,7 @@ cmdline_parse_token_string_t cmd_set_bonding_agg_mode_agg_mode =
cmdline_parse_token_num_t cmd_set_bonding_agg_mode_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_agg_mode_policy_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_bonding_agg_mode_policy_string =
TOKEN_STRING_INITIALIZER(
@@ -6364,11 +6364,11 @@ cmdline_parse_token_string_t cmd_set_burst_tx_retry_tx =
cmdline_parse_token_string_t cmd_set_burst_tx_retry_delay =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, delay, "delay");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_time =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, time, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_burst_tx_retry_retry =
TOKEN_STRING_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry, "retry");
cmdline_parse_token_num_t cmd_set_burst_tx_retry_retry_num =
- TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_burst_tx_retry_result, retry_num, RTE_UINT32);
cmdline_parse_inst_t cmd_set_burst_tx_retry = {
.f = cmd_set_burst_tx_retry_parsed,
@@ -6434,7 +6434,7 @@ cmdline_parse_token_string_t cmd_setpromisc_portall =
"all");
cmdline_parse_token_num_t cmd_setpromisc_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_promisc_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setpromisc_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_promisc_mode_result, mode,
"on#off");
@@ -6514,7 +6514,7 @@ cmdline_parse_token_string_t cmd_setallmulti_portall =
"all");
cmdline_parse_token_num_t cmd_setallmulti_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_set_allmulti_mode_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_setallmulti_mode =
TOKEN_STRING_INITIALIZER(struct cmd_set_allmulti_mode_result, mode,
"on#off");
@@ -6592,25 +6592,25 @@ cmdline_parse_token_string_t cmd_lfc_set_high_water_str =
hw_str, "high_water");
cmdline_parse_token_num_t cmd_lfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_low_water_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
lw_str, "low_water");
cmdline_parse_token_num_t cmd_lfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_string_t cmd_lfc_set_pause_time_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
pt_str, "pause_time");
cmdline_parse_token_num_t cmd_lfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_send_xon_str =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
xon_str, "send_xon");
cmdline_parse_token_num_t cmd_lfc_set_send_xon =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- send_xon, UINT16);
+ send_xon, RTE_UINT16);
cmdline_parse_token_string_t cmd_lfc_set_mac_ctrl_frame_fwd_mode =
TOKEN_STRING_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
mac_ctrl_frame_fwd, "mac_ctrl_frame_fwd");
@@ -6625,7 +6625,7 @@ cmdline_parse_token_string_t cmd_lfc_set_autoneg =
autoneg, "on#off");
cmdline_parse_token_num_t cmd_lfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_link_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
/* forward declaration */
static void
@@ -6920,19 +6920,19 @@ cmdline_parse_token_string_t cmd_pfc_set_tx_mode =
tx_pfc_mode, "on#off");
cmdline_parse_token_num_t cmd_pfc_set_high_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- high_water, UINT32);
+ high_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_low_water =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- low_water, UINT32);
+ low_water, RTE_UINT32);
cmdline_parse_token_num_t cmd_pfc_set_pause_time =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- pause_time, UINT16);
+ pause_time, RTE_UINT16);
cmdline_parse_token_num_t cmd_pfc_set_priority =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- priority, UINT8);
+ priority, RTE_UINT8);
cmdline_parse_token_num_t cmd_pfc_set_portid =
TOKEN_NUM_INITIALIZER(struct cmd_priority_flow_ctrl_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_priority_flow_control_set = {
.f = cmd_priority_flow_ctrl_set_parsed,
@@ -7070,7 +7070,7 @@ cmdline_parse_token_string_t cmd_start_tx_first_n_tx_first =
tx_first, "tx_first");
cmdline_parse_token_num_t cmd_start_tx_first_n_tx_num =
TOKEN_NUM_INITIALIZER(struct cmd_start_tx_first_n_result,
- tx_num, UINT32);
+ tx_num, RTE_UINT32);
cmdline_parse_inst_t cmd_start_tx_first_n = {
.f = cmd_start_tx_first_n_parsed,
@@ -7101,7 +7101,7 @@ cmdline_parse_token_string_t cmd_set_link_up_link_up =
cmdline_parse_token_string_t cmd_set_link_up_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_up_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_up_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_up_result, port_id, RTE_UINT16);
static void cmd_set_link_up_parsed(__attribute__((unused)) void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -7140,7 +7140,7 @@ cmdline_parse_token_string_t cmd_set_link_down_link_down =
cmdline_parse_token_string_t cmd_set_link_down_port =
TOKEN_STRING_INITIALIZER(struct cmd_set_link_down_result, port, "port");
cmdline_parse_token_num_t cmd_set_link_down_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_link_down_result, port_id, RTE_UINT16);
static void cmd_set_link_down_parsed(
__attribute__((unused)) void *parsed_result,
@@ -7327,7 +7327,7 @@ cmdline_parse_token_string_t cmd_showport_what =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, what,
"info#summary#stats#xstats#fdir#stat_qmap#dcb_tc#cap");
cmdline_parse_token_num_t cmd_showport_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, RTE_UINT16);
cmdline_parse_inst_t cmd_showport = {
.f = cmd_showport_parsed,
@@ -7373,9 +7373,9 @@ cmdline_parse_token_string_t cmd_showqueue_type =
cmdline_parse_token_string_t cmd_showqueue_what =
TOKEN_STRING_INITIALIZER(struct cmd_showqueue_result, what, "info");
cmdline_parse_token_num_t cmd_showqueue_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, portnum, RTE_UINT16);
cmdline_parse_token_num_t cmd_showqueue_queuenum =
- TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_showqueue_result, queuenum, RTE_UINT16);
cmdline_parse_inst_t cmd_showqueue = {
.f = cmd_showqueue_parsed,
@@ -7456,9 +7456,9 @@ cmdline_parse_token_string_t cmd_read_reg_read =
cmdline_parse_token_string_t cmd_read_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_read_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_result, reg_off, RTE_UINT32);
cmdline_parse_inst_t cmd_read_reg = {
.f = cmd_read_reg_parsed,
@@ -7501,16 +7501,16 @@ cmdline_parse_token_string_t cmd_read_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_read_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_read_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit_field = {
.f = cmd_read_reg_bit_field_parsed,
@@ -7552,11 +7552,11 @@ cmdline_parse_token_string_t cmd_read_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_read_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_read_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_read_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_inst_t cmd_read_reg_bit = {
.f = cmd_read_reg_bit_parsed,
@@ -7595,11 +7595,11 @@ cmdline_parse_token_string_t cmd_write_reg_write =
cmdline_parse_token_string_t cmd_write_reg_reg =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_result, reg, "reg");
cmdline_parse_token_num_t cmd_write_reg_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_result, value, RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg = {
.f = cmd_write_reg_parsed,
@@ -7644,19 +7644,19 @@ cmdline_parse_token_string_t cmd_write_reg_bit_field_regfield =
regfield, "regfield");
cmdline_parse_token_num_t cmd_write_reg_bit_field_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_field_reg_off =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, reg_off,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit1_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit1_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_bit2_pos =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, bit2_pos,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_field_value =
TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_field_result, value,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_write_reg_bit_field = {
.f = cmd_write_reg_bit_field_parsed,
@@ -7702,13 +7702,13 @@ cmdline_parse_token_string_t cmd_write_reg_bit_regbit =
TOKEN_STRING_INITIALIZER(struct cmd_write_reg_bit_result,
regbit, "regbit");
cmdline_parse_token_num_t cmd_write_reg_bit_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_write_reg_bit_reg_off =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, reg_off, RTE_UINT32);
cmdline_parse_token_num_t cmd_write_reg_bit_bit_pos =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, bit_pos, RTE_UINT8);
cmdline_parse_token_num_t cmd_write_reg_bit_value =
- TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_write_reg_bit_result, value, RTE_UINT8);
cmdline_parse_inst_t cmd_write_reg_bit = {
.f = cmd_write_reg_bit_parsed,
@@ -7754,11 +7754,11 @@ cmdline_parse_token_string_t cmd_read_rxd_txd_rxd_txd =
TOKEN_STRING_INITIALIZER(struct cmd_read_rxd_txd_result, rxd_txd,
"rxd#txd");
cmdline_parse_token_num_t cmd_read_rxd_txd_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_queue_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_read_rxd_txd_desc_id =
- TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_read_rxd_txd_result, desc_id, RTE_UINT16);
cmdline_parse_inst_t cmd_read_rxd_txd = {
.f = cmd_read_rxd_txd_parsed,
@@ -7836,7 +7836,7 @@ cmdline_parse_token_string_t cmd_mac_addr_what =
"add#remove#set");
cmdline_parse_token_num_t cmd_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_mac_addr_result, port_num,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -7882,7 +7882,7 @@ cmdline_parse_token_string_t cmd_eth_peer_set =
cmdline_parse_token_string_t cmd_eth_peer =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, eth_peer, "eth-peer");
cmdline_parse_token_num_t cmd_eth_peer_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_eth_peer_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_eth_peer_addr =
TOKEN_STRING_INITIALIZER(struct cmd_eth_peer_result, peer_addr, NULL);
@@ -7931,13 +7931,13 @@ cmdline_parse_token_string_t cmd_setqmap_what =
what, "tx#rx");
cmdline_parse_token_num_t cmd_setqmap_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_queueid =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_setqmap_mapvalue =
TOKEN_NUM_INITIALIZER(struct cmd_set_qmap_result,
- map_value, UINT8);
+ map_value, RTE_UINT8);
cmdline_parse_inst_t cmd_set_qmap = {
.f = cmd_set_qmap_parsed,
@@ -8033,7 +8033,7 @@ cmdline_parse_token_string_t cmd_set_uc_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_hash_table,
what, "uta");
@@ -8094,7 +8094,7 @@ cmdline_parse_token_string_t cmd_set_uc_all_hash_port =
port, "port");
cmdline_parse_token_num_t cmd_set_uc_all_hash_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_uc_all_hash_table,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_uc_all_hash_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_uc_all_hash_table,
what, "uta");
@@ -8186,13 +8186,13 @@ cmdline_parse_token_string_t cmd_set_vf_macvlan_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_macvlan_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_macvlan_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_macvlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_macvlan_vf_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_macvlan_filter,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_set_vf_macvlan_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_macvlan_filter,
address);
@@ -8255,13 +8255,13 @@ cmdline_parse_token_string_t cmd_setvf_traffic_port =
port, "port");
cmdline_parse_token_num_t cmd_setvf_traffic_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_setvf_traffic_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
vf, "vf");
cmdline_parse_token_num_t cmd_setvf_traffic_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_traffic,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_setvf_traffic_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_traffic,
what, "tx#rx");
@@ -8343,13 +8343,13 @@ cmdline_parse_token_string_t cmd_set_vf_rxmode_port =
port, "port");
cmdline_parse_token_num_t cmd_set_vf_rxmode_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_rxmode_vf =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
vf, "vf");
cmdline_parse_token_num_t cmd_set_vf_rxmode_vfid =
TOKEN_NUM_INITIALIZER(struct cmd_set_vf_rxmode,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vf_rxmode_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_vf_rxmode,
what, "rxmode");
@@ -8426,13 +8426,13 @@ cmdline_parse_token_string_t cmd_vf_mac_addr_port =
port,"port");
cmdline_parse_token_num_t cmd_vf_mac_addr_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_mac_addr_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_mac_addr_result,
vf,"vf");
cmdline_parse_token_num_t cmd_vf_mac_addr_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_mac_addr_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_etheraddr_t cmd_vf_mac_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_vf_mac_addr_result,
address);
@@ -8517,19 +8517,19 @@ cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vlanid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_port =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
port, "port");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_portid =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rx_vlan_filter_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rx_vlan_filter,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rx_vlan_filter_vf_mask =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rx_vlan_filter,
- vf_mask, UINT64);
+ vf_mask, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rxvlan_filter = {
.f = cmd_vf_rx_vlan_filter_parsed,
@@ -8584,19 +8584,19 @@ cmdline_parse_token_string_t cmd_queue_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_queue_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_rate_limit_queue =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
queue, "queue");
cmdline_parse_token_num_t cmd_queue_rate_limit_queuenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- queue_num, UINT8);
+ queue_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_queue_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_queue_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_queue_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_inst_t cmd_queue_rate_limit = {
.f = cmd_queue_rate_limit_parsed,
@@ -8654,25 +8654,25 @@ cmdline_parse_token_string_t cmd_vf_rate_limit_port =
port, "port");
cmdline_parse_token_num_t cmd_vf_rate_limit_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- port_num, UINT16);
+ port_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_vf =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
vf, "vf");
cmdline_parse_token_num_t cmd_vf_rate_limit_vfnum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- vf_num, UINT8);
+ vf_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_vf_rate_limit_rate =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
rate, "rate");
cmdline_parse_token_num_t cmd_vf_rate_limit_ratenum =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- rate_num, UINT16);
+ rate_num, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_rate_limit_q_msk =
TOKEN_STRING_INITIALIZER(struct cmd_vf_rate_limit_result,
q_msk, "queue_mask");
cmdline_parse_token_num_t cmd_vf_rate_limit_q_msk_val =
TOKEN_NUM_INITIALIZER(struct cmd_vf_rate_limit_result,
- q_msk_val, UINT64);
+ q_msk_val, RTE_UINT64);
cmdline_parse_inst_t cmd_vf_rate_limit = {
.f = cmd_vf_rate_limit_parsed,
@@ -8794,7 +8794,7 @@ cmdline_parse_token_string_t cmd_tunnel_filter_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_tunnel_filter_outer_mac =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_tunnel_filter_result,
outer_mac);
@@ -8803,7 +8803,7 @@ cmdline_parse_token_etheraddr_t cmd_tunnel_filter_inner_mac =
inner_mac);
cmdline_parse_token_num_t cmd_tunnel_filter_innner_vlan =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- inner_vlan, UINT16);
+ inner_vlan, RTE_UINT16);
cmdline_parse_token_ipaddr_t cmd_tunnel_filter_ip_value =
TOKEN_IPADDR_INITIALIZER(struct cmd_tunnel_filter_result,
ip_value);
@@ -8817,10 +8817,10 @@ cmdline_parse_token_string_t cmd_tunnel_filter_filter_type =
"imac#omac-imac-tenid");
cmdline_parse_token_num_t cmd_tunnel_filter_tenant_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- tenant_id, UINT32);
+ tenant_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_tunnel_filter_queue_num =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_filter_result,
- queue_num, UINT16);
+ queue_num, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_filter = {
.f = cmd_tunnel_filter_parsed,
@@ -8886,10 +8886,10 @@ cmdline_parse_token_string_t cmd_tunnel_udp_config_what =
what, "add#rm");
cmdline_parse_token_num_t cmd_tunnel_udp_config_udp_port =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- udp_port, UINT16);
+ udp_port, RTE_UINT16);
cmdline_parse_token_num_t cmd_tunnel_udp_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_tunnel_udp_config,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_tunnel_udp_config = {
.f = cmd_tunnel_udp_config_parsed,
@@ -8959,7 +8959,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_config =
"config");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_port =
TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port,
udp_tunnel_port,
@@ -8972,7 +8972,7 @@ cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
"vxlan#geneve#vxlan-gpe");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
.f = cmd_cfg_tunnel_udp_port_parsed,
@@ -9021,13 +9021,13 @@ cmdline_parse_token_string_t cmd_global_config_cmd =
"global_config");
cmdline_parse_token_num_t cmd_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_global_config_type =
TOKEN_STRING_INITIALIZER(struct cmd_global_config_result,
cfg_type, "gre-key-len");
cmdline_parse_token_num_t cmd_global_config_gre_key_len =
TOKEN_NUM_INITIALIZER(struct cmd_global_config_result,
- len, UINT8);
+ len, RTE_UINT8);
cmdline_parse_inst_t cmd_global_config = {
.f = cmd_global_config_parsed,
@@ -9064,13 +9064,13 @@ cmdline_parse_token_string_t cmd_mirror_mask_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_mask_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_mask_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_mask_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
what, "pool-mirror-up#pool-mirror-down"
@@ -9083,7 +9083,7 @@ cmdline_parse_token_string_t cmd_mirror_mask_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_mask_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_mask_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_mask_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_mask_result,
on, "on#off");
@@ -9179,13 +9179,13 @@ cmdline_parse_token_string_t cmd_mirror_link_port =
port, "port");
cmdline_parse_token_num_t cmd_mirror_link_portid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_mirror_link_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_mirror_link_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
what, "uplink-mirror#downlink-mirror");
@@ -9194,7 +9194,7 @@ cmdline_parse_token_string_t cmd_mirror_link_dstpool =
dstpool, "dst-pool");
cmdline_parse_token_num_t cmd_mirror_link_poolid =
TOKEN_NUM_INITIALIZER(struct cmd_set_mirror_link_result,
- dstpool_id, UINT8);
+ dstpool_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_mirror_link_on =
TOKEN_STRING_INITIALIZER(struct cmd_set_mirror_link_result,
on, "on#off");
@@ -9265,13 +9265,13 @@ cmdline_parse_token_string_t cmd_rm_mirror_rule_port =
port, "port");
cmdline_parse_token_num_t cmd_rm_mirror_rule_portid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rm_mirror_rule_mirror =
TOKEN_STRING_INITIALIZER(struct cmd_rm_mirror_rule_result,
mirror, "mirror-rule");
cmdline_parse_token_num_t cmd_rm_mirror_rule_ruleid =
TOKEN_NUM_INITIALIZER(struct cmd_rm_mirror_rule_result,
- rule_id, UINT8);
+ rule_id, RTE_UINT8);
static void
cmd_reset_mirror_rule_parsed(void *parsed_result,
@@ -9464,7 +9464,7 @@ cmdline_parse_token_string_t cmd_syn_filter_filter =
filter, "syn_filter");
cmdline_parse_token_num_t cmd_syn_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_syn_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_syn_filter_result,
ops, "add#del");
@@ -9479,7 +9479,7 @@ cmdline_parse_token_string_t cmd_syn_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_syn_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_syn_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_syn_filter = {
.f = cmd_syn_filter_parsed,
@@ -9556,7 +9556,7 @@ cmdline_parse_token_string_t cmd_queue_region_port =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result, port, "port");
cmdline_parse_token_num_t cmd_queue_region_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
cmd, "queue-region");
@@ -9565,19 +9565,19 @@ cmdline_parse_token_string_t cmd_queue_region_id =
region, "region_id");
cmdline_parse_token_num_t cmd_queue_region_index =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_start_index =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_start_index, "queue_start_index");
cmdline_parse_token_num_t cmd_queue_region_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_id, UINT8);
+ queue_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_queue_region_queue_num =
TOKEN_STRING_INITIALIZER(struct cmd_queue_region_result,
queue_num, "queue_num");
cmdline_parse_token_num_t cmd_queue_region_queue_num_value =
TOKEN_NUM_INITIALIZER(struct cmd_queue_region_result,
- queue_num_value, UINT8);
+ queue_num_value, RTE_UINT8);
cmdline_parse_inst_t cmd_queue_region = {
.f = cmd_queue_region_parsed,
@@ -9656,7 +9656,7 @@ cmdline_parse_token_string_t cmd_region_flowtype_port =
port, "port");
cmdline_parse_token_num_t cmd_region_flowtype_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_region_flowtype_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
cmd, "queue-region");
@@ -9665,13 +9665,13 @@ cmdline_parse_token_string_t cmd_region_flowtype_index =
region, "region_id");
cmdline_parse_token_num_t cmd_region_flowtype_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_region_flowtype_flow_index =
TOKEN_STRING_INITIALIZER(struct cmd_region_flowtype_result,
flowtype, "flowtype");
cmdline_parse_token_num_t cmd_region_flowtype_flow_id =
TOKEN_NUM_INITIALIZER(struct cmd_region_flowtype_result,
- flowtype_id, UINT8);
+ flowtype_id, RTE_UINT8);
cmdline_parse_inst_t cmd_region_flowtype = {
.f = cmd_region_flowtype_parsed,
.data = NULL,
@@ -9747,7 +9747,7 @@ cmdline_parse_token_string_t cmd_user_priority_region_port =
port, "port");
cmdline_parse_token_num_t cmd_user_priority_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_user_priority_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
cmd, "queue-region");
@@ -9756,13 +9756,13 @@ cmdline_parse_token_string_t cmd_user_priority_region_UP =
user_priority, "UP");
cmdline_parse_token_num_t cmd_user_priority_region_UP_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- user_priority_id, UINT8);
+ user_priority_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_user_priority_region_region =
TOKEN_STRING_INITIALIZER(struct cmd_user_priority_region_result,
region, "region_id");
cmdline_parse_token_num_t cmd_user_priority_region_region_id =
TOKEN_NUM_INITIALIZER(struct cmd_user_priority_region_result,
- region_id, UINT8);
+ region_id, RTE_UINT8);
cmdline_parse_inst_t cmd_user_priority_region = {
.f = cmd_user_priority_region_parsed,
@@ -9840,7 +9840,7 @@ cmdline_parse_token_string_t cmd_flush_queue_region_port =
port, "port");
cmdline_parse_token_num_t cmd_flush_queue_region_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_flush_queue_region_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flush_queue_region_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_flush_queue_region_result,
cmd, "queue-region");
@@ -9921,7 +9921,7 @@ cmdline_parse_token_string_t cmd_show_queue_region_info_port =
port, "port");
cmdline_parse_token_num_t cmd_show_queue_region_info_port_index =
TOKEN_NUM_INITIALIZER(struct cmd_show_queue_region_info,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_queue_region_info_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_show_queue_region_info,
cmd, "queue-region");
@@ -10022,7 +10022,7 @@ cmdline_parse_token_string_t cmd_2tuple_filter_filter =
filter, "2tuple_filter");
cmdline_parse_token_num_t cmd_2tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
ops, "add#del");
@@ -10031,37 +10031,37 @@ cmdline_parse_token_string_t cmd_2tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_2tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_2tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_2tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_2tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_2tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_2tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_2tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_2tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_2tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_2tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_2tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_2tuple_filter = {
.f = cmd_2tuple_filter_parsed,
@@ -10201,7 +10201,7 @@ cmdline_parse_token_string_t cmd_5tuple_filter_filter =
filter, "5tuple_filter");
cmdline_parse_token_num_t cmd_5tuple_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
ops, "add#del");
@@ -10222,43 +10222,43 @@ cmdline_parse_token_string_t cmd_5tuple_filter_dst_port =
dst_port, "dst_port");
cmdline_parse_token_num_t cmd_5tuple_filter_dst_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- dst_port_value, UINT16);
+ dst_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_src_port =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
src_port, "src_port");
cmdline_parse_token_num_t cmd_5tuple_filter_src_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- src_port_value, UINT16);
+ src_port_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_5tuple_filter_protocol =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
protocol, "protocol");
cmdline_parse_token_num_t cmd_5tuple_filter_protocol_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- protocol_value, UINT8);
+ protocol_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_mask =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
mask, "mask");
cmdline_parse_token_num_t cmd_5tuple_filter_mask_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- mask_value, INT8);
+ mask_value, RTE_INT8);
cmdline_parse_token_string_t cmd_5tuple_filter_tcp_flags =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
tcp_flags, "tcp_flags");
cmdline_parse_token_num_t cmd_5tuple_filter_tcp_flags_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- tcp_flags_value, UINT8);
+ tcp_flags_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_priority =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
priority, "priority");
cmdline_parse_token_num_t cmd_5tuple_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_5tuple_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_5tuple_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_5tuple_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_5tuple_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_5tuple_filter = {
.f = cmd_5tuple_filter_parsed,
@@ -10424,7 +10424,7 @@ cmdline_parse_token_string_t cmd_flex_filter_filter =
filter, "flex_filter");
cmdline_parse_token_num_t cmd_flex_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flex_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
ops, "add#del");
@@ -10433,7 +10433,7 @@ cmdline_parse_token_string_t cmd_flex_filter_len =
len, "len");
cmdline_parse_token_num_t cmd_flex_filter_len_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- len_value, UINT8);
+ len_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_bytes =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
bytes, "bytes");
@@ -10451,13 +10451,13 @@ cmdline_parse_token_string_t cmd_flex_filter_priority =
priority, "priority");
cmdline_parse_token_num_t cmd_flex_filter_priority_value =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- priority_value, UINT8);
+ priority_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flex_filter_queue =
TOKEN_STRING_INITIALIZER(struct cmd_flex_filter_result,
queue, "queue");
cmdline_parse_token_num_t cmd_flex_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flex_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_inst_t cmd_flex_filter = {
.f = cmd_flex_filter_parsed,
.data = NULL,
@@ -10503,7 +10503,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_filter =
filter, "ethertype_filter");
cmdline_parse_token_num_t cmd_ethertype_filter_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_ops =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
ops, "add#del");
@@ -10518,7 +10518,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_ethertype =
ethertype, "ethertype");
cmdline_parse_token_num_t cmd_ethertype_filter_ethertype_value =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- ethertype_value, UINT16);
+ ethertype_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_ethertype_filter_drop =
TOKEN_STRING_INITIALIZER(struct cmd_ethertype_filter_result,
drop, "drop#fwd");
@@ -10527,7 +10527,7 @@ cmdline_parse_token_string_t cmd_ethertype_filter_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_ethertype_filter_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_ethertype_filter_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
static void
cmd_ethertype_filter_parsed(void *parsed_result,
@@ -11003,7 +11003,7 @@ cmdline_parse_token_string_t cmd_flow_director_filter =
flow_director_filter, "flow_director_filter");
cmdline_parse_token_num_t cmd_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_ops =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ops, "add#del#update");
@@ -11018,7 +11018,7 @@ cmdline_parse_token_string_t cmd_flow_director_ether =
ether, "ether");
cmdline_parse_token_num_t cmd_flow_director_ether_type =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ether_type, UINT16);
+ ether_type, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
src, "src");
@@ -11027,7 +11027,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_src =
ip_src);
cmdline_parse_token_num_t cmd_flow_director_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
dst, "dst");
@@ -11036,37 +11036,37 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_ip_dst =
ip_dst);
cmdline_parse_token_num_t cmd_flow_director_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_verify_tag =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
verify_tag, "verify_tag");
cmdline_parse_token_num_t cmd_flow_director_verify_tag_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- verify_tag_value, UINT32);
+ verify_tag_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_tos =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
tos, "tos");
cmdline_parse_token_num_t cmd_flow_director_tos_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tos_value, UINT8);
+ tos_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_proto =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
proto, "proto");
cmdline_parse_token_num_t cmd_flow_director_proto_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- proto_value, UINT8);
+ proto_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
ttl, "ttl");
cmdline_parse_token_num_t cmd_flow_director_ttl_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- ttl_value, UINT8);
+ ttl_value, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- vlan_value, UINT16);
+ vlan_value, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexbytes =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
flexbytes, "flexbytes");
@@ -11084,13 +11084,13 @@ cmdline_parse_token_string_t cmd_flow_director_queue =
queue, "queue");
cmdline_parse_token_num_t cmd_flow_director_queue_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_fd_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
fd_id, "fd_id");
cmdline_parse_token_num_t cmd_flow_director_fd_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- fd_id_value, UINT32);
+ fd_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
@@ -11124,7 +11124,7 @@ cmdline_parse_token_string_t cmd_flow_director_tunnel_id =
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
- tunnel_id_value, UINT32);
+ tunnel_id_value, RTE_UINT32);
cmdline_parse_token_string_t cmd_flow_director_packet =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
packet, "packet");
@@ -11368,7 +11368,7 @@ cmdline_parse_token_string_t cmd_flush_flow_director_flush =
flush_flow_director, "flush_flow_director");
cmdline_parse_token_num_t cmd_flush_flow_director_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flush_flow_director_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_flush_flow_director_parsed(void *parsed_result,
@@ -11486,13 +11486,13 @@ cmdline_parse_token_string_t cmd_flow_director_mask =
flow_director_mask, "flow_director_mask");
cmdline_parse_token_num_t cmd_flow_director_mask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
vlan, "vlan");
cmdline_parse_token_num_t cmd_flow_director_mask_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- vlan_mask, UINT16);
+ vlan_mask, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
src_mask, "src_mask");
@@ -11504,7 +11504,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_src =
ipv6_src);
cmdline_parse_token_num_t cmd_flow_director_mask_port_src =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_src, UINT16);
+ port_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_dst =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
dst_mask, "dst_mask");
@@ -11516,7 +11516,7 @@ cmdline_parse_token_ipaddr_t cmd_flow_director_mask_ipv6_dst =
ipv6_dst);
cmdline_parse_token_num_t cmd_flow_director_mask_port_dst =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- port_dst, UINT16);
+ port_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_mask_mode =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
@@ -11535,19 +11535,19 @@ cmdline_parse_token_string_t cmd_flow_director_mask_mac =
mac, "mac");
cmdline_parse_token_num_t cmd_flow_director_mask_mac_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- mac_addr_byte_mask, UINT8);
+ mac_addr_byte_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_type, "tunnel-type");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_type_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_type_mask, UINT8);
+ tunnel_type_mask, RTE_UINT8);
cmdline_parse_token_string_t cmd_flow_director_mask_tunnel_id =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_mask_result,
tunnel_id, "tunnel-id");
cmdline_parse_token_num_t cmd_flow_director_mask_tunnel_id_value =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_mask_result,
- tunnel_id_mask, UINT32);
+ tunnel_id_mask, RTE_UINT32);
cmdline_parse_inst_t cmd_set_flow_director_ip_mask = {
.f = cmd_flow_director_mask_parsed,
@@ -11701,7 +11701,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexmask =
"flow_director_flex_mask");
cmdline_parse_token_num_t cmd_flow_director_flexmask_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flex_mask_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexmask_flow =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flex_mask_result,
flow, "flow");
@@ -11819,7 +11819,7 @@ cmdline_parse_token_string_t cmd_flow_director_flexpayload =
"flow_director_flex_payload");
cmdline_parse_token_num_t cmd_flow_director_flexpayload_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_flow_director_flexpayload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_flow_director_flexpayload_payload_layer =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flexpayload_result,
payload_layer, "raw#l2#l3#l4");
@@ -11887,7 +11887,7 @@ cmdline_parse_token_string_t cmd_get_sym_hash_ena_per_port_all =
get_sym_hash_ena_per_port, "get_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_get_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_sym_hash_ena_per_port = {
.f = cmd_get_sym_hash_per_port_parsed,
@@ -11943,7 +11943,7 @@ cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_all =
set_sym_hash_ena_per_port, "set_sym_hash_ena_per_port");
cmdline_parse_token_num_t cmd_set_sym_hash_ena_per_port_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_sym_hash_ena_per_port_enable =
TOKEN_STRING_INITIALIZER(struct cmd_set_sym_hash_ena_per_port_result,
enable, "enable#disable");
@@ -12065,7 +12065,7 @@ cmdline_parse_token_string_t cmd_get_hash_global_config_all =
get_hash_global_config, "get_hash_global_config");
cmdline_parse_token_num_t cmd_get_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_get_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_inst_t cmd_get_hash_global_config = {
.f = cmd_get_hash_global_config_parsed,
@@ -12137,7 +12137,7 @@ cmdline_parse_token_string_t cmd_set_hash_global_config_all =
set_hash_global_config, "set_hash_global_config");
cmdline_parse_token_num_t cmd_set_hash_global_config_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_global_config_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_global_config_hash_func =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_global_config_result,
hash_func, "toeplitz#simple_xor#default");
@@ -12253,7 +12253,7 @@ cmdline_parse_token_string_t cmd_set_hash_input_set_cmd =
set_hash_input_set, "set_hash_input_set");
cmdline_parse_token_num_t cmd_set_hash_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_hash_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_hash_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_hash_input_set_result,
flow_type, NULL);
@@ -12326,7 +12326,7 @@ cmdline_parse_token_string_t cmd_set_fdir_input_set_cmd =
set_fdir_input_set, "set_fdir_input_set");
cmdline_parse_token_num_t cmd_set_fdir_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_fdir_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_fdir_input_set_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_set_fdir_input_set_result,
flow_type,
@@ -12399,7 +12399,7 @@ cmdline_parse_token_string_t cmd_mcast_addr_what =
TOKEN_STRING_INITIALIZER(struct cmd_mcast_addr_result, what,
"add#remove");
cmdline_parse_token_num_t cmd_mcast_addr_portnum =
- TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_mcast_addr_result, port_num, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_mcast_addr_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_mac_addr_result, address);
@@ -12448,7 +12448,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
@@ -12464,7 +12464,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_eth_type_eth_type =
cmdline_parse_token_num_t cmd_config_l2_tunnel_eth_type_eth_type_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_eth_type_result,
- eth_type_val, UINT16);
+ eth_type_val, RTE_UINT16);
static enum rte_eth_tunnel_type
str2fdir_l2_tunnel_type(char *string)
@@ -12582,7 +12582,7 @@ cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_all_str =
cmdline_parse_token_num_t cmd_config_l2_tunnel_en_dis_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
- id, UINT16);
+ id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_l2_tunnel_en_dis_l2_tunnel =
TOKEN_STRING_INITIALIZER
(struct cmd_config_l2_tunnel_en_dis_result,
@@ -12760,7 +12760,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_port_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_tag_id_val, UINT32);
+ port_tag_id_val, RTE_UINT32);
cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12768,7 +12768,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_e_tag_id =
cmdline_parse_token_num_t cmd_config_e_tag_e_tag_id_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- e_tag_id_val, UINT16);
+ e_tag_id_val, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12776,7 +12776,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_dst_pool =
cmdline_parse_token_num_t cmd_config_e_tag_dst_pool_val =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- dst_pool_val, UINT8);
+ dst_pool_val, RTE_UINT8);
cmdline_parse_token_string_t cmd_config_e_tag_port =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12784,7 +12784,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_port =
cmdline_parse_token_num_t cmd_config_e_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_e_tag_vf =
TOKEN_STRING_INITIALIZER
(struct cmd_config_e_tag_result,
@@ -12792,7 +12792,7 @@ cmdline_parse_token_string_t cmd_config_e_tag_vf =
cmdline_parse_token_num_t cmd_config_e_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_e_tag_result,
- vf_id, UINT8);
+ vf_id, RTE_UINT8);
/* E-tag insertion configuration */
static void
@@ -13111,11 +13111,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_vlan_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_anti_spoof_result,
@@ -13217,11 +13217,11 @@ cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_antispoof =
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_mac_anti_spoof_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_mac_anti_spoof_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_mac_anti_spoof_result,
@@ -13323,11 +13323,11 @@ cmdline_parse_token_string_t cmd_vf_vlan_stripq_stripq =
cmdline_parse_token_num_t cmd_vf_vlan_stripq_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_stripq_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_vlan_stripq_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_vlan_stripq_result,
@@ -13429,15 +13429,15 @@ cmdline_parse_token_string_t cmd_vf_vlan_insert_insert =
cmdline_parse_token_num_t cmd_vf_vlan_insert_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_vlan_insert_vlan_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_vlan_insert_result,
- vlan_id, UINT16);
+ vlan_id, RTE_UINT16);
static void
cmd_set_vf_vlan_insert_parsed(
@@ -13527,7 +13527,7 @@ cmdline_parse_token_string_t cmd_tx_loopback_loopback =
cmdline_parse_token_num_t cmd_tx_loopback_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_loopback_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_loopback_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_loopback_result,
@@ -13627,7 +13627,7 @@ cmdline_parse_token_string_t cmd_all_queues_drop_en_drop =
cmdline_parse_token_num_t cmd_all_queues_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_all_queues_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_all_queues_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_all_queues_drop_en_result,
@@ -13719,11 +13719,11 @@ cmdline_parse_token_string_t cmd_vf_split_drop_en_drop =
cmdline_parse_token_num_t cmd_vf_split_drop_en_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_split_drop_en_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_split_drop_en_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_vf_split_drop_en_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_split_drop_en_result,
@@ -13813,11 +13813,11 @@ cmdline_parse_token_string_t cmd_set_vf_mac_addr_addr =
cmdline_parse_token_num_t cmd_set_vf_mac_addr_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_mac_addr_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_mac_addr_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_set_vf_mac_addr_mac_addr =
TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vf_mac_addr_result,
mac_addr);
@@ -13914,7 +13914,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_on_offload =
cmdline_parse_token_num_t cmd_macsec_offload_on_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_on_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_on_on =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_on_result,
@@ -14026,7 +14026,7 @@ cmdline_parse_token_string_t cmd_macsec_offload_off_offload =
cmdline_parse_token_num_t cmd_macsec_offload_off_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_offload_off_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_macsec_offload_off_off =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_offload_off_result,
@@ -14118,7 +14118,7 @@ cmdline_parse_token_string_t cmd_macsec_sc_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
TOKEN_ETHERADDR_INITIALIZER
(struct cmd_macsec_sc_result,
@@ -14126,7 +14126,7 @@ cmdline_parse_token_etheraddr_t cmd_macsec_sc_mac =
cmdline_parse_token_num_t cmd_macsec_sc_pi =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sc_result,
- pi, UINT16);
+ pi, RTE_UINT16);
static void
cmd_set_macsec_sc_parsed(
@@ -14210,19 +14210,19 @@ cmdline_parse_token_string_t cmd_macsec_sa_tx_rx =
cmdline_parse_token_num_t cmd_macsec_sa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_macsec_sa_idx =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- idx, UINT8);
+ idx, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_an =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- an, UINT8);
+ an, RTE_UINT8);
cmdline_parse_token_num_t cmd_macsec_sa_pn =
TOKEN_NUM_INITIALIZER
(struct cmd_macsec_sa_result,
- pn, UINT32);
+ pn, RTE_UINT32);
cmdline_parse_token_string_t cmd_macsec_sa_key =
TOKEN_STRING_INITIALIZER
(struct cmd_macsec_sa_result,
@@ -14330,11 +14330,11 @@ cmdline_parse_token_string_t cmd_vf_promisc_promisc =
cmdline_parse_token_num_t cmd_vf_promisc_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_promisc_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_promisc_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_promisc_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_promisc_result,
@@ -14420,11 +14420,11 @@ cmdline_parse_token_string_t cmd_vf_allmulti_allmulti =
cmdline_parse_token_num_t cmd_vf_allmulti_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_allmulti_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_allmulti_result,
- vf_id, UINT32);
+ vf_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_allmulti_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_allmulti_result,
@@ -14510,11 +14510,11 @@ cmdline_parse_token_string_t cmd_set_vf_broadcast_broadcast =
cmdline_parse_token_num_t cmd_set_vf_broadcast_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_broadcast_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_broadcast_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_broadcast_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_broadcast_result,
@@ -14604,11 +14604,11 @@ cmdline_parse_token_string_t cmd_set_vf_vlan_tag_tag =
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_vf_vlan_tag_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vf_vlan_tag_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_set_vf_vlan_tag_result,
@@ -14714,19 +14714,19 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_max_bw =
cmdline_parse_token_num_t cmd_vf_tc_bw_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_no =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_no, UINT8);
+ tc_no, RTE_UINT8);
cmdline_parse_token_num_t cmd_vf_tc_bw_bw =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- bw, UINT32);
+ bw, RTE_UINT32);
cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
TOKEN_STRING_INITIALIZER
(struct cmd_vf_tc_bw_result,
@@ -14734,7 +14734,7 @@ cmdline_parse_token_string_t cmd_vf_tc_bw_bw_list =
cmdline_parse_token_num_t cmd_vf_tc_bw_tc_map =
TOKEN_NUM_INITIALIZER
(struct cmd_vf_tc_bw_result,
- tc_map, UINT8);
+ tc_map, RTE_UINT8);
/* VF max bandwidth setting */
static void
@@ -15039,7 +15039,7 @@ cmdline_parse_token_string_t cmd_set_port_tm_hierarchy_default_default =
cmdline_parse_token_num_t cmd_set_port_tm_hierarchy_default_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_hierarchy_default_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_set_port_tm_hierarchy_default_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -15119,27 +15119,27 @@ cmdline_parse_token_string_t cmd_set_vxlan_vni =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vni");
cmdline_parse_token_num_t cmd_set_vxlan_vni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_vxlan_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-src");
cmdline_parse_token_num_t cmd_set_vxlan_udp_src_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"udp-dst");
cmdline_parse_token_num_t cmd_set_vxlan_udp_dst_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_ip_tos =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-tos");
cmdline_parse_token_num_t cmd_set_vxlan_ip_tos_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tos, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_ttl =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-ttl");
cmdline_parse_token_num_t cmd_set_vxlan_ip_ttl_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, UINT8);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, ttl, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_vxlan_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"ip-src");
@@ -15154,7 +15154,7 @@ cmdline_parse_token_string_t cmd_set_vxlan_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_vxlan_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_vxlan_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, pos_token,
"eth-src");
@@ -15339,7 +15339,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_tni =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"tni");
cmdline_parse_token_num_t cmd_set_nvgre_tni_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, RTE_UINT32);
cmdline_parse_token_string_t cmd_set_nvgre_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"ip-src");
@@ -15354,7 +15354,7 @@ cmdline_parse_token_string_t cmd_set_nvgre_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_nvgre_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_nvgre_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, pos_token,
"eth-src");
@@ -15485,7 +15485,7 @@ cmdline_parse_token_string_t cmd_set_l2_encap_vlan =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"vlan-tci");
cmdline_parse_token_num_t cmd_set_l2_encap_vlan_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_l2_encap_result, tci, RTE_UINT16);
cmdline_parse_token_string_t cmd_set_l2_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_l2_encap_result, pos_token,
"eth-src");
@@ -15645,7 +15645,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "ip-src");
@@ -15661,7 +15661,7 @@ cmdline_parse_token_string_t cmd_set_mplsogre_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsogre_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsogre_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsogre_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsogre_encap_result,
pos_token, "eth-src");
@@ -15869,19 +15869,19 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_label =
pos_token, "label");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_label_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, label,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-src");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_src_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_src,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_udp_dst =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "udp-dst");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_udp_dst_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, udp_dst,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_ip_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "ip-src");
@@ -15897,7 +15897,7 @@ cmdline_parse_token_string_t cmd_set_mplsoudp_encap_vlan =
pos_token, "vlan-tci");
cmdline_parse_token_num_t cmd_set_mplsoudp_encap_vlan_value =
TOKEN_NUM_INITIALIZER(struct cmd_set_mplsoudp_encap_result, tci,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_set_mplsoudp_encap_eth_src =
TOKEN_STRING_INITIALIZER(struct cmd_set_mplsoudp_encap_result,
pos_token, "eth-src");
@@ -16140,7 +16140,7 @@ cmdline_parse_token_string_t cmd_ddp_add_ddp =
cmdline_parse_token_string_t cmd_ddp_add_add =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, add, "add");
cmdline_parse_token_num_t cmd_ddp_add_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_add_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_add_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_add_result, filepath, NULL);
@@ -16220,7 +16220,7 @@ cmdline_parse_token_string_t cmd_ddp_del_ddp =
cmdline_parse_token_string_t cmd_ddp_del_del =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, del, "del");
cmdline_parse_token_num_t cmd_ddp_del_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_del_result, port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_ddp_del_filepath =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_del_result, filepath, NULL);
@@ -16527,7 +16527,7 @@ cmdline_parse_token_string_t cmd_ddp_get_list_get =
cmdline_parse_token_string_t cmd_ddp_get_list_list =
TOKEN_STRING_INITIALIZER(struct cmd_ddp_get_list_result, list, "list");
cmdline_parse_token_num_t cmd_ddp_get_list_port_id =
- TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cmd_ddp_get_list_result, port_id, RTE_UINT16);
static void
cmd_ddp_get_list_parsed(
@@ -16676,13 +16676,13 @@ cmdline_parse_token_string_t cmd_cfg_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_cfg_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_cfg_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_cfg_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_cfg_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_cfg_input_set_result,
inset_type,
@@ -16695,7 +16695,7 @@ cmdline_parse_token_string_t cmd_cfg_input_set_field =
field, "field");
cmdline_parse_token_num_t cmd_cfg_input_set_field_idx =
TOKEN_NUM_INITIALIZER(struct cmd_cfg_input_set_result,
- field_idx, UINT8);
+ field_idx, RTE_UINT8);
cmdline_parse_inst_t cmd_cfg_input_set = {
.f = cmd_cfg_input_set_parsed,
@@ -16777,13 +16777,13 @@ cmdline_parse_token_string_t cmd_clear_input_set_cfg =
cfg, "config");
cmdline_parse_token_num_t cmd_clear_input_set_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_clear_input_set_pctype =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
pctype, "pctype");
cmdline_parse_token_num_t cmd_clear_input_set_pctype_id =
TOKEN_NUM_INITIALIZER(struct cmd_clear_input_set_result,
- pctype_id, UINT8);
+ pctype_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_clear_input_set_inset_type =
TOKEN_STRING_INITIALIZER(struct cmd_clear_input_set_result,
inset_type,
@@ -16840,11 +16840,11 @@ cmdline_parse_token_string_t cmd_show_vf_stats_stats =
cmdline_parse_token_num_t cmd_show_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_show_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_show_vf_stats_parsed(
@@ -16949,11 +16949,11 @@ cmdline_parse_token_string_t cmd_clear_vf_stats_stats =
cmdline_parse_token_num_t cmd_clear_vf_stats_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_clear_vf_stats_vf_id =
TOKEN_NUM_INITIALIZER
(struct cmd_clear_vf_stats_result,
- vf_id, UINT16);
+ vf_id, RTE_UINT16);
static void
cmd_clear_vf_stats_parsed(
@@ -17033,7 +17033,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_reset_config =
cmdline_parse_token_num_t cmd_pctype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_reset_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_reset_result,
@@ -17115,7 +17115,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_get_port =
cmdline_parse_token_num_t cmd_pctype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_get_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_get_result,
@@ -17219,7 +17219,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_config =
cmdline_parse_token_num_t cmd_pctype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_pctype_mapping_update_pctype =
TOKEN_STRING_INITIALIZER
(struct cmd_pctype_mapping_update_result,
@@ -17239,7 +17239,7 @@ cmdline_parse_token_string_t cmd_pctype_mapping_update_pc_type =
cmdline_parse_token_num_t cmd_pctype_mapping_update_flow_type =
TOKEN_NUM_INITIALIZER
(struct cmd_pctype_mapping_update_result,
- flow_type, UINT16);
+ flow_type, RTE_UINT16);
static void
cmd_pctype_mapping_update_parsed(
@@ -17333,11 +17333,11 @@ cmdline_parse_token_string_t cmd_ptype_mapping_get_get =
cmdline_parse_token_num_t cmd_ptype_mapping_get_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_get_valid_only =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_get_result,
- valid_only, UINT8);
+ valid_only, RTE_UINT8);
static void
cmd_ptype_mapping_get_parsed(
@@ -17430,19 +17430,19 @@ cmdline_parse_token_string_t cmd_ptype_mapping_replace_replace =
cmdline_parse_token_num_t cmd_ptype_mapping_replace_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_target =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- target, UINT32);
+ target, RTE_UINT32);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_mask =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- mask, UINT8);
+ mask, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_replace_pkt_type =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_replace_result,
- pkt_type, UINT32);
+ pkt_type, RTE_UINT32);
static void
cmd_ptype_mapping_replace_parsed(
@@ -17524,7 +17524,7 @@ cmdline_parse_token_string_t cmd_ptype_mapping_reset_reset =
cmdline_parse_token_num_t cmd_ptype_mapping_reset_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_reset_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void
cmd_ptype_mapping_reset_parsed(
@@ -17597,15 +17597,15 @@ cmdline_parse_token_string_t cmd_ptype_mapping_update_update =
cmdline_parse_token_num_t cmd_ptype_mapping_update_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_ptype_mapping_update_hw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- hw_ptype, UINT8);
+ hw_ptype, RTE_UINT8);
cmdline_parse_token_num_t cmd_ptype_mapping_update_sw_ptype =
TOKEN_NUM_INITIALIZER
(struct cmd_ptype_mapping_update_result,
- sw_ptype, UINT32);
+ sw_ptype, RTE_UINT32);
static void
cmd_ptype_mapping_update_parsed(
@@ -17716,7 +17716,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_rx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_capa_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_capa_result,
@@ -17809,7 +17809,7 @@ cmdline_parse_token_string_t cmd_rx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_rx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_rx_offload_get_configuration_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_rx_offload_get_configuration_result,
@@ -17887,7 +17887,7 @@ cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_rx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -18005,7 +18005,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18013,7 +18013,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxq =
cmdline_parse_token_num_t cmd_config_per_queue_rx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_rx_offload_result_rxoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_rx_offload_result,
@@ -18110,7 +18110,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_capa_port =
cmdline_parse_token_num_t cmd_tx_offload_get_capa_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_capa_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_capa_result,
@@ -18203,7 +18203,7 @@ cmdline_parse_token_string_t cmd_tx_offload_get_configuration_port =
cmdline_parse_token_num_t cmd_tx_offload_get_configuration_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_tx_offload_get_configuration_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_tx_offload_get_configuration_result,
@@ -18281,7 +18281,7 @@ cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_config =
cmdline_parse_token_num_t cmd_config_per_port_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_port_tx_offload_result_tx_offload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_tx_offload_result,
@@ -18406,7 +18406,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_port =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_port_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18414,7 +18414,7 @@ cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txq =
cmdline_parse_token_num_t cmd_config_per_queue_tx_offload_result_queue_id =
TOKEN_NUM_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
- queue_id, UINT16);
+ queue_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_per_queue_tx_offload_result_txoffload =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_queue_tx_offload_result,
@@ -18527,13 +18527,13 @@ cmdline_parse_token_string_t cmd_config_tx_metadata_specific_keyword =
keyword, "config");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_id =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_config_tx_metadata_specific_item =
TOKEN_STRING_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
item, "tx_metadata");
cmdline_parse_token_num_t cmd_config_tx_metadata_specific_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tx_metadata_specific_result,
- value, UINT32);
+ value, RTE_UINT32);
cmdline_parse_inst_t cmd_config_tx_metadata_specific = {
.f = cmd_config_tx_metadata_specific_parsed,
@@ -18582,7 +18582,7 @@ cmdline_parse_token_string_t cmd_show_tx_metadata_port =
cmd_port, "port");
cmdline_parse_token_num_t cmd_show_tx_metadata_pid =
TOKEN_NUM_INITIALIZER(struct cmd_show_tx_metadata_result,
- cmd_pid, UINT16);
+ cmd_pid, RTE_UINT16);
cmdline_parse_token_string_t cmd_show_tx_metadata_keyword =
TOKEN_STRING_INITIALIZER(struct cmd_show_tx_metadata_result,
cmd_keyword, "tx_metadata");
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..423bf6e66 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -253,7 +253,7 @@ cmdline_parse_token_string_t cmd_show_port_meter_cap_cap =
struct cmd_show_port_meter_cap_result, cap, "cap");
cmdline_parse_token_num_t cmd_show_port_meter_cap_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_cap_result, port_id, UINT16);
+ struct cmd_show_port_meter_cap_result, port_id, RTE_UINT16);
static void cmd_show_port_meter_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -359,23 +359,23 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_srtcm_srtcm_rfc2697 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_srtcm_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_srtcm_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_srtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -461,27 +461,27 @@ cmdline_parse_token_string_t cmd_add_port_meter_profile_trtcm_trtcm_rfc2698 =
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pir, UINT64);
+ pir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_pbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_result,
- pbs, UINT64);
+ pbs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -571,27 +571,27 @@ cmdline_parse_token_string_t
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cir, UINT64);
+ cir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_eir =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- eir, UINT64);
+ eir, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_cbs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- cbs, UINT64);
+ cbs, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_meter_profile_trtcm_rfc4115_ebs =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_meter_profile_trtcm_rfc4115_result,
- ebs, UINT64);
+ ebs, RTE_UINT64);
static void cmd_add_port_meter_profile_trtcm_rfc4115_parsed(
void *parsed_result,
@@ -672,11 +672,11 @@ cmdline_parse_token_string_t cmd_del_port_meter_profile_profile =
cmdline_parse_token_num_t cmd_del_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_meter_profile_result,
- profile_id, UINT32);
+ profile_id, RTE_UINT32);
static void cmd_del_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -742,13 +742,13 @@ cmdline_parse_token_string_t cmd_create_port_meter_meter =
struct cmd_create_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_create_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, port_id, UINT16);
+ struct cmd_create_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_create_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, mtr_id, UINT32);
+ struct cmd_create_port_meter_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_create_port_meter_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_create_port_meter_result, profile_id, UINT32);
+ struct cmd_create_port_meter_result, profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_meter_enable =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_enable, "yes#no");
@@ -763,10 +763,10 @@ cmdline_parse_token_string_t cmd_create_port_meter_r_action =
r_action, "R#Y#G#D#r#y#g#d");
cmdline_parse_token_num_t cmd_create_port_meter_statistics_mask =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- statistics_mask, UINT64);
+ statistics_mask, RTE_UINT64);
cmdline_parse_token_num_t cmd_create_port_meter_shared =
TOKEN_NUM_INITIALIZER(struct cmd_create_port_meter_result,
- shared, UINT32);
+ shared, RTE_UINT32);
cmdline_parse_token_string_t cmd_create_port_meter_input_color =
TOKEN_STRING_INITIALIZER(struct cmd_create_port_meter_result,
meter_input_color, TOKEN_STRING_MULTI);
@@ -866,10 +866,10 @@ cmdline_parse_token_string_t cmd_enable_port_meter_meter =
struct cmd_enable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_enable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, port_id, UINT16);
+ struct cmd_enable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_enable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_enable_port_meter_result, mtr_id, UINT32);
+ struct cmd_enable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_enable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -927,10 +927,10 @@ cmdline_parse_token_string_t cmd_disable_port_meter_meter =
struct cmd_disable_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_disable_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, port_id, UINT16);
+ struct cmd_disable_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_disable_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_disable_port_meter_result, mtr_id, UINT32);
+ struct cmd_disable_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_disable_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -988,10 +988,10 @@ cmdline_parse_token_string_t cmd_del_port_meter_meter =
struct cmd_del_port_meter_result, meter, "meter");
cmdline_parse_token_num_t cmd_del_port_meter_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, port_id, UINT16);
+ struct cmd_del_port_meter_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_meter_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_del_port_meter_result, mtr_id, UINT32);
+ struct cmd_del_port_meter_result, mtr_id, RTE_UINT32);
static void cmd_del_port_meter_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1054,13 +1054,13 @@ cmdline_parse_token_string_t cmd_set_port_meter_profile_profile =
struct cmd_set_port_meter_profile_result, profile, "profile");
cmdline_parse_token_num_t cmd_set_port_meter_profile_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, port_id, UINT16);
+ struct cmd_set_port_meter_profile_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_profile_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_profile_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_profile_profile_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_profile_result, profile_id, UINT32);
+ struct cmd_set_port_meter_profile_result, profile_id, RTE_UINT32);
static void cmd_set_port_meter_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1208,15 +1208,15 @@ cmdline_parse_token_string_t cmd_set_port_meter_policer_action_action =
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, port_id,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_mtr_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, mtr_id,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_policer_action_action_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_policer_action_result, action_mask,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_set_port_meter_policer_action_policer_action =
TOKEN_STRING_INITIALIZER(
struct cmd_set_port_meter_policer_action_result,
@@ -1316,14 +1316,14 @@ cmdline_parse_token_string_t cmd_set_port_meter_stats_mask_mask =
struct cmd_set_port_meter_stats_mask_result, mask, "mask");
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, port_id, UINT16);
+ struct cmd_set_port_meter_stats_mask_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_meter_stats_mask_result, mtr_id, UINT32);
+ struct cmd_set_port_meter_stats_mask_result, mtr_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_meter_stats_mask_stats_mask =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_meter_stats_mask_result, stats_mask,
- UINT64);
+ RTE_UINT64);
static void cmd_set_port_meter_stats_mask_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1388,10 +1388,10 @@ cmdline_parse_token_string_t cmd_show_port_meter_stats_stats =
struct cmd_show_port_meter_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_meter_stats_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, port_id, UINT16);
+ struct cmd_show_port_meter_stats_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_meter_stats_mtr_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_meter_stats_result, mtr_id, UINT32);
+ struct cmd_show_port_meter_stats_result, mtr_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_show_port_meter_stats_clear =
TOKEN_STRING_INITIALIZER(
struct cmd_show_port_meter_stats_result, clear, "yes#no");
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..c0d846422 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -217,7 +217,7 @@ cmdline_parse_token_string_t cmd_show_port_tm_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
static void cmd_show_port_tm_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -354,10 +354,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_level_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_level_cap_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_level_cap_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
static void cmd_show_port_tm_level_cap_parsed(void *parsed_result,
@@ -481,10 +481,10 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_cap_cap =
cap, "cap");
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_cap_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_cap_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_cap_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -593,14 +593,14 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_stats_stats =
struct cmd_show_port_tm_node_stats_result, stats, "stats");
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_show_port_tm_node_stats_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_stats_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_show_port_tm_node_stats_clear =
TOKEN_NUM_INITIALIZER(
- struct cmd_show_port_tm_node_stats_result, clear, UINT32);
+ struct cmd_show_port_tm_node_stats_result, clear, RTE_UINT32);
static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -712,11 +712,11 @@ cmdline_parse_token_string_t cmd_show_port_tm_node_type_type =
cmdline_parse_token_num_t cmd_show_port_tm_node_type_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_show_port_tm_node_type_node_id =
TOKEN_NUM_INITIALIZER(
struct cmd_show_port_tm_node_type_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_show_port_tm_node_type_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -804,31 +804,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_rate, UINT64);
+ cmit_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_cmit_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- cmit_tb_size, UINT64);
+ cmit_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_rate =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_rate, UINT64);
+ peak_tb_rate, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_peak_tb_size =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- peak_tb_size, UINT64);
+ peak_tb_size, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_shaper_profile_pktlen_adjust =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shaper_profile_result,
- pktlen_adjust, UINT32);
+ pktlen_adjust, RTE_UINT32);
static void cmd_add_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -920,11 +920,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shaper_profile_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shaper_profile_result,
- shaper_id, UINT32);
+ shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1001,15 +1001,15 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_node_shared_shaper_shaper_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_shared_shaper_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_add_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1101,11 +1101,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_shared_shaper_shaper =
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_shared_shaper_shared_shaper_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_shared_shaper_result,
- shared_shaper_id, UINT32);
+ shared_shaper_id, RTE_UINT32);
static void cmd_del_port_tm_node_shared_shaper_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1194,11 +1194,11 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1206,19 +1206,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_g =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_g, UINT64);
+ min_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_g, UINT64);
+ max_th_g, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_g, UINT16);
+ maxp_inv_g, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_g =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_g, UINT16);
+ wq_log2_g, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1226,19 +1226,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_y =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_y, UINT64);
+ min_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_y, UINT64);
+ max_th_y, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_y, UINT16);
+ maxp_inv_y, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_y =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_y, UINT16);
+ wq_log2_y, RTE_UINT16);
cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
TOKEN_STRING_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
@@ -1246,19 +1246,19 @@ cmdline_parse_token_string_t cmd_add_port_tm_node_wred_profile_color_r =
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_min_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- min_th_r, UINT64);
+ min_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_max_th_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- max_th_r, UINT64);
+ max_th_r, RTE_UINT64);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_maxp_inv_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- maxp_inv_r, UINT16);
+ maxp_inv_r, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_node_wred_profile_wq_log2_r =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_node_wred_profile_result,
- wq_log2_r, UINT16);
+ wq_log2_r, RTE_UINT16);
static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
@@ -1374,11 +1374,11 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_wred_profile_profile =
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_wred_profile_wred_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_del_port_tm_node_wred_profile_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
static void cmd_del_port_tm_node_wred_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1456,15 +1456,15 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_shaper_profile_profile =
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_shaper_profile_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_shaper_profile_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t
cmd_set_port_tm_node_shaper_shaper_profile_profile_id =
TOKEN_NUM_INITIALIZER(
struct cmd_set_port_tm_node_shaper_profile_result,
- shaper_profile_id, UINT32);
+ shaper_profile_id, RTE_UINT32);
static void cmd_set_port_tm_node_shaper_profile_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1550,31 +1550,31 @@ cmdline_parse_token_string_t cmd_add_port_tm_nonleaf_node_node =
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_add_port_tm_nonleaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_n_sp_priorities =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- n_sp_priorities, UINT32);
+ n_sp_priorities, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_nonleaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_nonleaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_nonleaf_node_result,
@@ -1708,34 +1708,34 @@ cmdline_parse_token_string_t cmd_add_port_tm_leaf_node_node =
struct cmd_add_port_tm_leaf_node_result, node, "node");
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_parent_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- parent_node_id, INT32);
+ parent_node_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_priority =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_weight =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- weight, UINT32);
+ weight, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_level_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- level_id, UINT32);
+ level_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_shaper_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- shaper_profile_id, INT32);
+ shaper_profile_id, RTE_INT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_cman_mode =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- cman_mode, UINT32);
+ cman_mode, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_wred_profile_id =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- wred_profile_id, UINT32);
+ wred_profile_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_add_port_tm_leaf_node_stats_mask =
TOKEN_NUM_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
- stats_mask, UINT64);
+ stats_mask, RTE_UINT64);
cmdline_parse_token_string_t
cmd_add_port_tm_leaf_node_multi_shared_shaper_id =
TOKEN_STRING_INITIALIZER(struct cmd_add_port_tm_leaf_node_result,
@@ -1858,10 +1858,10 @@ cmdline_parse_token_string_t cmd_del_port_tm_node_node =
struct cmd_del_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_del_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_del_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(struct cmd_del_port_tm_node_result,
- node_id, UINT32);
+ node_id, RTE_UINT32);
static void cmd_del_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -1936,19 +1936,19 @@ cmdline_parse_token_string_t cmd_set_port_tm_node_parent_parent =
struct cmd_set_port_tm_node_parent_result, parent, "parent");
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, port_id, UINT16);
+ struct cmd_set_port_tm_node_parent_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_set_port_tm_node_parent_result, node_id, UINT32);
+ struct cmd_set_port_tm_node_parent_result, node_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_parent_id =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- parent_id, UINT32);
+ parent_id, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_priority =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- priority, UINT32);
+ priority, RTE_UINT32);
cmdline_parse_token_num_t cmd_set_port_tm_node_parent_weight =
TOKEN_NUM_INITIALIZER(struct cmd_set_port_tm_node_parent_result,
- weight, UINT32);
+ weight, RTE_UINT32);
static void cmd_set_port_tm_node_parent_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2024,10 +2024,10 @@ cmdline_parse_token_string_t cmd_suspend_port_tm_node_node =
struct cmd_suspend_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_suspend_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, port_id, UINT16);
+ struct cmd_suspend_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_suspend_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_suspend_port_tm_node_result, node_id, UINT32);
+ struct cmd_suspend_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_suspend_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2089,10 +2089,10 @@ cmdline_parse_token_string_t cmd_resume_port_tm_node_node =
struct cmd_resume_port_tm_node_result, node, "node");
cmdline_parse_token_num_t cmd_resume_port_tm_node_port_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, port_id, UINT16);
+ struct cmd_resume_port_tm_node_result, port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_resume_port_tm_node_node_id =
TOKEN_NUM_INITIALIZER(
- struct cmd_resume_port_tm_node_result, node_id, UINT32);
+ struct cmd_resume_port_tm_node_result, node_id, RTE_UINT32);
static void cmd_resume_port_tm_node_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2156,7 +2156,7 @@ cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_commit =
cmdline_parse_token_num_t cmd_port_tm_hierarchy_commit_port_id =
TOKEN_NUM_INITIALIZER(
struct cmd_port_tm_hierarchy_commit_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_string_t cmd_port_tm_hierarchy_commit_clean_on_fail =
TOKEN_STRING_INITIALIZER(struct cmd_port_tm_hierarchy_commit_result,
clean_on_fail, "yes#no");
@@ -2236,17 +2236,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_ecn_ip_ecn =
ip_ecn, "ip_ecn");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_ecn_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_ecn_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_ecn_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2323,17 +2323,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_ip_dscp_ip_dscp =
ip_dscp, "ip_dscp");
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_ip_dscp_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_ip_dscp_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_ip_dscp_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -2410,17 +2410,17 @@ cmdline_parse_token_string_t cmd_port_tm_mark_vlan_dei_vlan_dei =
vlan_dei, "vlan_dei");
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_port_id =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- port_id, UINT16);
+ port_id, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_green =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- green, UINT16);
+ green, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_yellow =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- yellow, UINT16);
+ yellow, RTE_UINT16);
cmdline_parse_token_num_t cmd_port_tm_mark_vlan_dei_red =
TOKEN_NUM_INITIALIZER(struct cmd_port_tm_mark_vlan_dei_result,
- red, UINT16);
+ red, RTE_UINT16);
static void cmd_port_tm_mark_vlan_dei_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
diff --git a/app/test/test_cmdline_num.c b/app/test/test_cmdline_num.c
index 4c97caf3d..71a6a7fa8 100644
--- a/app/test/test_cmdline_num.c
+++ b/app/test/test_cmdline_num.c
@@ -233,31 +233,31 @@ static int
can_parse_unsigned(uint64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX)
return 0;
break;
- case INT64:
+ case RTE_INT64:
if (expected_result > INT64_MAX)
return 0;
break;
@@ -271,31 +271,31 @@ static int
can_parse_signed(int64_t expected_result, enum cmdline_numtype type)
{
switch (type) {
- case UINT8:
+ case RTE_UINT8:
if (expected_result > UINT8_MAX || expected_result < 0)
return 0;
break;
- case UINT16:
+ case RTE_UINT16:
if (expected_result > UINT16_MAX || expected_result < 0)
return 0;
break;
- case UINT32:
+ case RTE_UINT32:
if (expected_result > UINT32_MAX || expected_result < 0)
return 0;
break;
- case UINT64:
+ case RTE_UINT64:
if (expected_result < 0)
return 0;
break;
- case INT8:
+ case RTE_INT8:
if (expected_result > INT8_MAX || expected_result < INT8_MIN)
return 0;
break;
- case INT16:
+ case RTE_INT16:
if (expected_result > INT16_MAX || expected_result < INT16_MIN)
return 0;
break;
- case INT32:
+ case RTE_INT32:
if (expected_result > INT32_MAX || expected_result < INT32_MIN)
return 0;
break;
@@ -315,7 +315,7 @@ test_parse_num_invalid_param(void)
int ret = 0;
/* set up a token */
- token.num_data.type = UINT32;
+ token.num_data.type = RTE_UINT32;
/* copy string to buffer */
strlcpy(buf, num_valid_positive_strs[0].str, sizeof(buf));
@@ -388,7 +388,7 @@ test_parse_num_invalid_data(void)
cmdline_parse_token_num_t token;
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test full strings */
@@ -427,7 +427,7 @@ test_parse_num_valid(void)
/** valid strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive strings */
@@ -481,13 +481,13 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
result = (int8_t) result;
break;
- case INT16:
+ case RTE_INT16:
result = (int16_t) result;
break;
- case INT32:
+ case RTE_INT32:
result = (int32_t) result;
break;
default:
@@ -505,7 +505,7 @@ test_parse_num_valid(void)
/** garbage strings **/
/* cycle through all possible parsed types */
- for (type = UINT8; type <= INT64; type++) {
+ for (type = RTE_UINT8; type <= RTE_INT64; type++) {
token.num_data.type = type;
/* test positive garbage strings */
@@ -559,15 +559,15 @@ test_parse_num_valid(void)
if (ret > 0) {
/* detect negative */
switch (type) {
- case INT8:
+ case RTE_INT8:
if (result & (INT8_MAX + 1))
result |= 0xFFFFFFFFFFFFFF00ULL;
break;
- case INT16:
+ case RTE_INT16:
if (result & (INT16_MAX + 1))
result |= 0xFFFFFFFFFFFF0000ULL;
break;
- case INT32:
+ case RTE_INT32:
if (result & (INT32_MAX + 1ULL))
result |= 0xFFFFFFFF00000000ULL;
break;
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c..d660f441a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -192,6 +192,10 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* cmdline: the numeric types to be used when defining cmdline parameters
+ have been renamed to have an ``RTE_`` prefix. For example, ``UINT8`` now
+ becomes ``RTE_UINT8``.
+
ABI Changes
-----------
diff --git a/examples/ethtool/ethtool-app/ethapp.c b/examples/ethtool/ethtool-app/ethapp.c
index a4e64b354..22f293904 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -70,7 +70,7 @@ cmdline_parse_token_string_t pcmd_rxmode_token_cmd =
cmdline_parse_token_string_t pcmd_portstats_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "portstats");
cmdline_parse_token_num_t pcmd_int_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, RTE_UINT16);
/* Commands taking port id and string */
cmdline_parse_token_string_t pcmd_eeprom_token_cmd =
@@ -84,7 +84,7 @@ cmdline_parse_token_string_t pcmd_regs_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "regs");
cmdline_parse_token_num_t pcmd_intstr_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_intstr_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, opt, NULL);
@@ -92,7 +92,7 @@ cmdline_parse_token_string_t pcmd_intstr_token_opt =
cmdline_parse_token_string_t pcmd_macaddr_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intmac_params, cmd, "macaddr");
cmdline_parse_token_num_t pcmd_intmac_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intmac_params, port, RTE_UINT16);
cmdline_parse_token_etheraddr_t pcmd_intmac_token_mac =
TOKEN_ETHERADDR_INITIALIZER(struct pcmd_intmac_params, mac);
@@ -106,18 +106,18 @@ cmdline_parse_token_string_t pcmd_ringparam_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intintint_params, cmd,
"ringparam");
cmdline_parse_token_num_t pcmd_intintint_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, port, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_tx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, tx, RTE_UINT16);
cmdline_parse_token_num_t pcmd_intintint_token_rx =
- TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intintint_params, rx, RTE_UINT16);
/* Pause commands */
cmdline_parse_token_string_t pcmd_pause_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params, cmd, "pause");
cmdline_parse_token_num_t pcmd_pause_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_intstr_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_pause_token_opt =
TOKEN_STRING_INITIALIZER(struct pcmd_intstr_params,
opt, "all#tx#rx#none");
@@ -126,11 +126,11 @@ cmdline_parse_token_string_t pcmd_pause_token_opt =
cmdline_parse_token_string_t pcmd_vlan_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, cmd, "vlan");
cmdline_parse_token_num_t pcmd_vlan_token_port =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, port, RTE_UINT16);
cmdline_parse_token_string_t pcmd_vlan_token_mode =
TOKEN_STRING_INITIALIZER(struct pcmd_vlan_params, mode, "add#del");
cmdline_parse_token_num_t pcmd_vlan_token_vid =
- TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, UINT16);
+ TOKEN_NUM_INITIALIZER(struct pcmd_vlan_params, vid, RTE_UINT16);
static void
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index b0a8ee23b..523b46d6b 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -516,7 +516,7 @@ cmdline_parse_token_string_t cfg_add_neigh_start =
cmdline_parse_token_string_t cfg_add_neigh_pstr =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, pstr, "port");
cmdline_parse_token_num_t cfg_add_neigh_port =
- TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, UINT16);
+ TOKEN_NUM_INITIALIZER(struct cfg_neigh_add_item, port, RTE_UINT16);
cmdline_parse_token_string_t cfg_add_neigh_mac =
TOKEN_STRING_INITIALIZER(struct cfg_neigh_add_item, mac, NULL);
diff --git a/examples/qos_sched/cmdline.c b/examples/qos_sched/cmdline.c
index 15f51830c..b163b6f9f 100644
--- a/examples/qos_sched/cmdline.c
+++ b/examples/qos_sched/cmdline.c
@@ -113,7 +113,7 @@ cmdline_parse_token_string_t cmd_setqavg_param_string =
"period#n");
cmdline_parse_token_num_t cmd_setqavg_number =
TOKEN_NUM_INITIALIZER(struct cmd_setqavg_result, number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_setqavg = {
.f = cmd_setqavg_parsed,
@@ -188,10 +188,10 @@ cmdline_parse_token_string_t cmd_subportstats_subport_string =
"subport");
cmdline_parse_token_num_t cmd_subportstats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_num_t cmd_subportstats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_subportstats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_inst_t cmd_subportstats = {
.f = cmd_subportstats_parsed,
@@ -236,19 +236,19 @@ cmdline_parse_token_string_t cmd_pipestats_port_string =
"port");
cmdline_parse_token_num_t cmd_pipestats_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_pipestats_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_pipestats_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_pipestats_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_pipestats_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_pipestats_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_pipestats_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_pipestats = {
.f = cmd_pipestats_parsed,
@@ -299,31 +299,31 @@ cmdline_parse_token_string_t cmd_avg_q_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_q_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_q_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_q_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_q_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_q_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_q_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_token_string_t cmd_avg_q_q_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_q_result, q_string,
"q");
cmdline_parse_token_num_t cmd_avg_q_q_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_q_result, q_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_q = {
.f = cmd_avg_q_parsed,
@@ -376,25 +376,25 @@ cmdline_parse_token_string_t cmd_avg_tcpipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcpipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcpipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcpipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_tcpipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcpipe_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcpipe_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcpipe_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcpipe_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcpipe = {
.f = cmd_avg_tcpipe_parsed,
@@ -443,19 +443,19 @@ cmdline_parse_token_string_t cmd_avg_pipe_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_pipe_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_pipe_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_pipe_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_pipe_pipe_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_pipe_result, pipe_string,
"pipe");
cmdline_parse_token_num_t cmd_avg_pipe_pipe_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_pipe_result, pipe_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_pipe = {
.f = cmd_avg_pipe_parsed,
@@ -502,19 +502,19 @@ cmdline_parse_token_string_t cmd_avg_tcsubport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_tcsubport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_tcsubport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_tcsubport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_token_string_t cmd_avg_tcsubport_tc_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_tcsubport_result, tc_string,
"tc");
cmdline_parse_token_num_t cmd_avg_tcsubport_tc_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_tcsubport_result, tc_number,
- UINT8);
+ RTE_UINT8);
cmdline_parse_inst_t cmd_avg_tcsubport = {
.f = cmd_avg_tcsubport_parsed,
@@ -559,13 +559,13 @@ cmdline_parse_token_string_t cmd_avg_subport_port_string =
"port");
cmdline_parse_token_num_t cmd_avg_subport_port_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, port_number,
- UINT16);
+ RTE_UINT16);
cmdline_parse_token_string_t cmd_avg_subport_subport_string =
TOKEN_STRING_INITIALIZER(struct cmd_avg_subport_result, subport_string,
"subport");
cmdline_parse_token_num_t cmd_avg_subport_subport_number =
TOKEN_NUM_INITIALIZER(struct cmd_avg_subport_result, subport_number,
- UINT32);
+ RTE_UINT32);
cmdline_parse_inst_t cmd_avg_subport = {
.f = cmd_avg_subport_parsed,
diff --git a/examples/quota_watermark/qwctl/commands.c b/examples/quota_watermark/qwctl/commands.c
index a1c646b9f..3f0cef7f1 100644
--- a/examples/quota_watermark/qwctl/commands.c
+++ b/examples/quota_watermark/qwctl/commands.c
@@ -74,7 +74,7 @@ cmdline_parse_token_string_t cmd_set_variable =
TOKEN_STRING_INITIALIZER(struct cmd_set_tokens, variable, NULL);
cmdline_parse_token_num_t cmd_set_value =
- TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, UINT32);
+ TOKEN_NUM_INITIALIZER(struct cmd_set_tokens, value, RTE_UINT32);
static void
cmd_set_handler(__attribute__((unused)) void *parsed_result,
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 2d9e7689a..82e1a0a03 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -160,7 +160,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_string_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- lcore_id, UINT8);
+ lcore_id, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/examples/vm_power_manager/vm_power_cli.c b/examples/vm_power_manager/vm_power_cli.c
index 41e89ff20..98e61a4ac 100644
--- a/examples/vm_power_manager/vm_power_cli.c
+++ b/examples/vm_power_manager/vm_power_cli.c
@@ -155,10 +155,10 @@ cmdline_parse_token_string_t cmd_set_pcpu_vm_name =
vm_name, NULL);
cmdline_parse_token_num_t set_pcpu_vcpu =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- vcpu, UINT8);
+ vcpu, RTE_UINT8);
cmdline_parse_token_num_t set_pcpu_core =
TOKEN_NUM_INITIALIZER(struct cmd_set_pcpu_result,
- core, UINT64);
+ core, RTE_UINT64);
cmdline_parse_inst_t cmd_set_pcpu_set = {
@@ -408,7 +408,7 @@ cmdline_parse_token_string_t cmd_show_cpu_freq =
cmdline_parse_token_num_t cmd_show_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_show_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_inst_t cmd_show_cpu_freq_set = {
.f = cmd_show_cpu_freq_parsed,
@@ -457,7 +457,7 @@ cmdline_parse_token_string_t cmd_set_cpu_freq =
set_cpu_freq, "set_cpu_freq");
cmdline_parse_token_num_t cmd_set_cpu_freq_core_num =
TOKEN_NUM_INITIALIZER(struct cmd_set_cpu_freq_result,
- core_num, UINT8);
+ core_num, RTE_UINT8);
cmdline_parse_token_string_t cmd_set_cpu_freq_cmd_cmd =
TOKEN_STRING_INITIALIZER(struct cmd_set_cpu_freq_result,
cmd, "up#down#min#max#enable_turbo#disable_turbo");
diff --git a/lib/librte_cmdline/cmdline_parse_num.c b/lib/librte_cmdline/cmdline_parse_num.c
index 182ac12f0..37d094893 100644
--- a/lib/librte_cmdline/cmdline_parse_num.c
+++ b/lib/librte_cmdline/cmdline_parse_num.c
@@ -69,23 +69,23 @@ static int
check_res_size(struct cmdline_token_num_data *nd, unsigned ressize)
{
switch (nd->type) {
- case INT8:
- case UINT8:
+ case RTE_INT8:
+ case RTE_UINT8:
if (ressize < sizeof(int8_t))
return -1;
break;
- case INT16:
- case UINT16:
+ case RTE_INT16:
+ case RTE_UINT16:
if (ressize < sizeof(int16_t))
return -1;
break;
- case INT32:
- case UINT32:
+ case RTE_INT32:
+ case RTE_UINT32:
if (ressize < sizeof(int32_t))
return -1;
break;
- case INT64:
- case UINT64:
+ case RTE_INT64:
+ case RTE_UINT64:
if (ressize < sizeof(int64_t))
return -1;
break;
@@ -259,35 +259,35 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
case HEX_OK:
case OCTAL_OK:
case BIN_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX ) {
if (res) *(int8_t *)res = (int8_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= INT16_MAX ) {
+ else if ( nd.type == RTE_INT16 && res1 <= INT16_MAX ) {
if (res) *(int16_t *)res = (int16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= INT32_MAX ) {
+ else if ( nd.type == RTE_INT32 && res1 <= INT32_MAX ) {
if (res) *(int32_t *)res = (int32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= INT64_MAX ) {
+ else if ( nd.type == RTE_INT64 && res1 <= INT64_MAX ) {
if (res) *(int64_t *)res = (int64_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT8 && res1 <= UINT8_MAX ) {
+ else if ( nd.type == RTE_UINT8 && res1 <= UINT8_MAX ) {
if (res) *(uint8_t *)res = (uint8_t) res1;
return buf-srcbuf;
}
- else if (nd.type == UINT16 && res1 <= UINT16_MAX ) {
+ else if (nd.type == RTE_UINT16 && res1 <= UINT16_MAX ) {
if (res) *(uint16_t *)res = (uint16_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT32 && res1 <= UINT32_MAX ) {
+ else if ( nd.type == RTE_UINT32 && res1 <= UINT32_MAX ) {
if (res) *(uint32_t *)res = (uint32_t) res1;
return buf-srcbuf;
}
- else if ( nd.type == UINT64 ) {
+ else if ( nd.type == RTE_UINT64 ) {
if (res) *(uint64_t *)res = res1;
return buf-srcbuf;
}
@@ -297,19 +297,19 @@ cmdline_parse_num(cmdline_parse_token_hdr_t *tk, const char *srcbuf, void *res,
break;
case DEC_NEG_OK:
- if ( nd.type == INT8 && res1 <= INT8_MAX + 1 ) {
+ if ( nd.type == RTE_INT8 && res1 <= INT8_MAX + 1 ) {
if (res) *(int8_t *)res = (int8_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
+ else if ( nd.type == RTE_INT16 && res1 <= (uint16_t)INT16_MAX + 1 ) {
if (res) *(int16_t *)res = (int16_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
+ else if ( nd.type == RTE_INT32 && res1 <= (uint32_t)INT32_MAX + 1 ) {
if (res) *(int32_t *)res = (int32_t) (-res1);
return buf-srcbuf;
}
- else if ( nd.type == INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
+ else if ( nd.type == RTE_INT64 && res1 <= (uint64_t)INT64_MAX + 1 ) {
if (res) *(int64_t *)res = (int64_t) (-res1);
return buf-srcbuf;
}
diff --git a/lib/librte_cmdline/cmdline_parse_num.h b/lib/librte_cmdline/cmdline_parse_num.h
index 58b28cad7..02133bb21 100644
--- a/lib/librte_cmdline/cmdline_parse_num.h
+++ b/lib/librte_cmdline/cmdline_parse_num.h
@@ -14,14 +14,14 @@ extern "C" {
#endif
enum cmdline_numtype {
- UINT8 = 0,
- UINT16,
- UINT32,
- UINT64,
- INT8,
- INT16,
- INT32,
- INT64
+ RTE_UINT8 = 0,
+ RTE_UINT16,
+ RTE_UINT32,
+ RTE_UINT64,
+ RTE_INT8,
+ RTE_INT16,
+ RTE_INT32,
+ RTE_INT64
};
struct cmdline_token_num_data {
--
2.20.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
@ 2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark return code functions as experimental
since this value might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/release_19_05.rst | 6 +++
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 50 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..32aae5d3bcfa 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,12 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..6cf4d7abb0bd 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 959ef9ece4b2..dc9f3dc0843d 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int __rte_experimental
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned int
-rte_lcore_to_socket_id(unsigned int lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
` (2 preceding siblings ...)
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
3 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-10 17:15 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure less visible
as part of the ABI. This version does not break the ABI (yet)
follow on patch moves lcore_config into eal_private.h
The changes in v2 is to:
- new patch to use unsigned int in lcore.h first
- incorporate feedback from David
- don't include last patch to make it private
(to avoid accidental early merge)
Stephen Hemminger (5):
eal: use unsigned int in rte_lcore.h functions
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 +++---
app/test/test_ring_perf.c | 22 +++++----
app/test/test_stack_perf.c | 20 ++++----
doc/guides/rel_notes/release_19_05.rst | 6 +++
drivers/bus/dpaa/dpaa_bus.c | 6 ++-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 5 +-
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 58 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 136 insertions(+), 51 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
@ 2019-04-10 9:43 4% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-10 9:43 UTC (permalink / raw)
To: Honnappa Nagarahalli, Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: nd
On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote:
> > I guess the short story is that DPDK ABI hasn't really settled down
> > as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature
> > project
> > with a similar intent, a framework for building applications, and
> > which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-
> > integration
> > and re-validation effort for new versions of DPDK. This effort from
> > their
> > perspective may not add value to their consuming project,
> > particular if
> > they are only updating to "stay current".
>
> Even if the ABI did not change, any claim of support with newer
> version needs re-validation. I think, re-integration is the only
> extra effort.
From first-hand experience: re-integration and re-validation are
different in scope and resource requirements.
Validation is usually done by the QA group, and usually doesn't cover
just one library that makes up a part of a product. In other words,
whether the DPDK version changes or not, a new version of a product
will typically undergo full regression testing anyway.
Integration is done by the development group. Any engineering-days that
have to be dedicated to re-integrate a new version of DPDK are
resources taken away from development of new features or bug fixing.
Maintenance costs of OSS components are a sometimes overlooked but
critical part of correctly scoping the opex of a project, and it's
something that product/project managers do look at.
> Why would anyone like to move to newer version just to stay current
> if the newer version does not add any value to them? IMO, this is
> doing work for no benefit.
For many reasons. For example the argument I always use is that while
new version Y might not be needed, new version Z might suddenly become
required for the successful delivery of critical feature A, or to fix
critical bug B.
In my experience, jumping from version X to Y and then Y to Z is always
cheaper and quicker and lower effort than jumping from X to Z, and the
larger the jump, the more work it is.
Another reason is that it's orders of magnitude cheaper to consume
dependencies from the base distribution of choice when building a Linux
product, rather than vendorizing. Doing that has of course drawbacks,
including not being in control of the version of dependencies - so you
don't have a choice, you need to keep up as the base distro moves on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-10 9:43 4% ` Luca Boccassi
2019-04-10 9:43 4% ` Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-10 9:43 UTC (permalink / raw)
To: Honnappa Nagarahalli, Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: nd
On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote:
> > I guess the short story is that DPDK ABI hasn't really settled down
> > as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature
> > project
> > with a similar intent, a framework for building applications, and
> > which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-
> > integration
> > and re-validation effort for new versions of DPDK. This effort from
> > their
> > perspective may not add value to their consuming project,
> > particular if
> > they are only updating to "stay current".
>
> Even if the ABI did not change, any claim of support with newer
> version needs re-validation. I think, re-integration is the only
> extra effort.
>From first-hand experience: re-integration and re-validation are
different in scope and resource requirements.
Validation is usually done by the QA group, and usually doesn't cover
just one library that makes up a part of a product. In other words,
whether the DPDK version changes or not, a new version of a product
will typically undergo full regression testing anyway.
Integration is done by the development group. Any engineering-days that
have to be dedicated to re-integrate a new version of DPDK are
resources taken away from development of new features or bug fixing.
Maintenance costs of OSS components are a sometimes overlooked but
critical part of correctly scoping the opex of a project, and it's
something that product/project managers do look at.
> Why would anyone like to move to newer version just to stay current
> if the newer version does not add any value to them? IMO, this is
> doing work for no benefit.
For many reasons. For example the argument I always use is that while
new version Y might not be needed, new version Z might suddenly become
required for the successful delivery of critical feature A, or to fix
critical bug B.
In my experience, jumping from version X to Y and then Y to Z is always
cheaper and quicker and lower effort than jumping from X to Z, and the
larger the jump, the more work it is.
Another reason is that it's orders of magnitude cheaper to consume
dependencies from the base distribution of choice when building a Linux
product, rather than vendorizing. Doing that has of course drawbacks,
including not being in control of the version of dependencies - so you
don't have a choice, you need to keep up as the base distro moves on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 9:16 0% ` Bruce Richardson
@ 2019-04-10 9:16 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-10 9:16 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, John McNamara, Marko Kovacevic, Ferruh Yigit
On Wed, Apr 10, 2019 at 10:36:25AM +0200, Olivier Matz wrote:
> As discussed at techboard, the network definitions, structures
> and functions will be prefixed by 'rte_'.
>
> Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
> Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ba39c2d62..36bc21ff8 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> +* network includes: Network structures, definitions and functions will
> + be prefixed by ``rte_`` to resolve conflicts with libc headers.
> + This change will break many DPDK APIs.
> +
> * meson: The minimum supported version of meson for configuring and building
> DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> those users with a version earlier than 0.47.1, an updated copy of meson
> --
> 2.11.0
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
@ 2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 9:16 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-10 9:16 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, John McNamara, Marko Kovacevic, Ferruh Yigit
On Wed, Apr 10, 2019 at 10:36:25AM +0200, Olivier Matz wrote:
> As discussed at techboard, the network definitions, structures
> and functions will be prefixed by 'rte_'.
>
> Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
> Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index ba39c2d62..36bc21ff8 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> +* network includes: Network structures, definitions and functions will
> + be prefixed by ``rte_`` to resolve conflicts with libc headers.
> + This change will break many DPDK APIs.
> +
> * meson: The minimum supported version of meson for configuring and building
> DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> those users with a version earlier than 0.47.1, an updated copy of meson
> --
> 2.11.0
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-10 9:03 8% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-10 9:03 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard, nd
On Wed, Apr 10, 2019 at 05:14:43AM +0000, Honnappa Nagarahalli wrote:
> >
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received from
> > a number of users of DPDK about ABI churn. In turn this feedback then
> > prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> This link can be used to check which structures are not needed to be exposed to the application.
> For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-integration
> > and re-validation effort for new versions of DPDK. This effort from their
> > perspective may not add value to their consuming project, particular if
> > they are only updating to "stay current".
> Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
> Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
>
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their projects
> > to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically
> > graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS releases.
> > A final removal notice will be published to the DPDK Mailing List, and if
> > there are no strong objections only then an API may be removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
> >
> > Shared Libraries
> > 6. DPDK will move to shared libraries & dynamic linking by default, to
> > accommodate greater use of ABI versioning by DPDK consumers.
> +1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
> Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
>
We do sometimes, but not enough. If we mandated ABI compatibility, or made
ABI breaks harder, I think we'd see greater adoption of this versioning
(something I am very much favour of).
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
@ 2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-10 9:03 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard, nd
On Wed, Apr 10, 2019 at 05:14:43AM +0000, Honnappa Nagarahalli wrote:
> >
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received from
> > a number of users of DPDK about ABI churn. In turn this feedback then
> > prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> This link can be used to check which structures are not needed to be exposed to the application.
> For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as the
> > project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive releases
> > since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant re-integration
> > and re-validation effort for new versions of DPDK. This effort from their
> > perspective may not add value to their consuming project, particular if
> > they are only updating to "stay current".
> Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
> Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
>
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their projects
> > to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically
> > graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS releases.
> > A final removal notice will be published to the DPDK Mailing List, and if
> > there are no strong objections only then an API may be removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
> >
> > Shared Libraries
> > 6. DPDK will move to shared libraries & dynamic linking by default, to
> > accommodate greater use of ABI versioning by DPDK consumers.
> +1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
> Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
>
We do sometimes, but not enough. If we mandated ABI compatibility, or made
ABI breaks harder, I think we'd see greater adoption of this versioning
(something I am very much favour of).
/Bruce
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
@ 2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:36 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, Ferruh Yigit
As discussed at techboard, the network definitions, structures
and functions will be prefixed by 'rte_'.
Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ba39c2d62..36bc21ff8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* network includes: Network structures, definitions and functions will
+ be prefixed by ``rte_`` to resolve conflicts with libc headers.
+ This change will break many DPDK APIs.
+
* meson: The minimum supported version of meson for configuring and building
DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
those users with a version earlier than 0.47.1, an updated copy of meson
--
2.11.0
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs
@ 2019-04-10 8:36 5% Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:36 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, Ferruh Yigit
As discussed at techboard, the network definitions, structures
and functions will be prefixed by 'rte_'.
Link: http://mails.dpdk.org/archives/dev/2019-February/125033.html
Link: https://mails.dpdk.org/archives/dev/2019-April/129752.html
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ba39c2d62..36bc21ff8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,10 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* network includes: Network structures, definitions and functions will
+ be prefixed by ``rte_`` to resolve conflicts with libc headers.
+ This change will break many DPDK APIs.
+
* meson: The minimum supported version of meson for configuring and building
DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
those users with a version earlier than 0.47.1, an updated copy of meson
--
2.11.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-10 8:35 4% ` David Marchand
@ 2019-04-10 8:35 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-10 8:35 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
However, there are two use cases that i can think of that are either
> hard or outright not possible without our multiprocess API's. The first
> one is dumping functionality. For example, dpdk_proc_info can display
> info from a currently-running or defunct process - list its
> memzones/mempools/etc. - basically, everything there is to know about
> the shared memory can be known that way. While this isn't a "real" use
> case, it is useful for debugging.
>
On the principle (there might be some corner cases I don't have an idea of)
attaching an existing process is something that can be done with PTRACE_*.
As for dumping post mortem, again, this could be done without dpdk assist.
The only thing that should come from dpdk is the knowledge of where and how
to dump the objects.
> More importantly, our multiprocess model provides resilience. In an
> event of a crash, the entire application is not brought down - instead,
> only the crashed process goes down. It's not /perfect/ resilience, of
> course, and there are caveats (memory leaking, locks, etc.), but you do
> get /some/ resilience that way - your process went down, you spin
> another secondary and you're back up and running again.
>
Never witnessed a recover, and yes I would suspect quite some funny
situations like locks, dirty memory etc...
Okay, thanks for the inputs.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-04-10 8:35 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 5:52 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
However, there are two use cases that i can think of that are either
> hard or outright not possible without our multiprocess API's. The first
> one is dumping functionality. For example, dpdk_proc_info can display
> info from a currently-running or defunct process - list its
> memzones/mempools/etc. - basically, everything there is to know about
> the shared memory can be known that way. While this isn't a "real" use
> case, it is useful for debugging.
>
On the principle (there might be some corner cases I don't have an idea of)
attaching an existing process is something that can be done with PTRACE_*.
As for dumping post mortem, again, this could be done without dpdk assist.
The only thing that should come from dpdk is the knowledge of where and how
to dump the objects.
> More importantly, our multiprocess model provides resilience. In an
> event of a crash, the entire application is not brought down - instead,
> only the crashed process goes down. It's not /perfect/ resilience, of
> course, and there are caveats (memory leaking, locks, etc.), but you do
> get /some/ resilience that way - your process went down, you spin
> another secondary and you're back up and running again.
>
Never witnessed a recover, and yes I would suspect quite some funny
situations like locks, dirty memory etc...
Okay, thanks for the inputs.
--
David Marchand
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [RFC v2 00/14] prefix network structures
2019-04-10 8:32 1% ` [dpdk-dev] [RFC v2 " Olivier Matz
@ 2019-04-10 8:32 1% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-10 8:32 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
This RFC targets 19.08.
The rte_net headers conflict with the libc headers, because
some definitions are duplicated, sometimes with few differences.
This RFC adds the rte_ (or RTE_) prefix to all structures, functions
and defines in rte_net library. This is a big changeset, that will
break the API of many functions, but not the ABI.
This was discussed in [1], and recently requested by the techboard [2].
v2:
* rebase on top of v19.05-rc1
[1] http://mails.dpdk.org/archives/dev/2018-January/087384.html
[2] http://mails.dpdk.org/archives/dev/2019-February/125033.html
Olivier Matz (14):
net: add rte prefix to arp structures
net: add rte prefix to arp defines
net: add rte prefix to ether structures
net: add rte prefix to ether functions
net: add rte prefix to ether defines
net: add rte prefix to esp structure
net: add rte prefix to gre structure
net: add rte prefix to icmp structure
net: add rte prefix to icmp defines
net: add rte prefix to ip structure
net: add rte prefix to ip defines
net: add rte prefix to sctp structure
net: add rte prefix to tcp structure
net: add rte prefix to udp structure
app/pdump/main.c | 2 +-
app/test-acl/main.c | 2 +-
app/test-eventdev/test_perf_common.c | 2 +-
app/test-eventdev/test_pipeline_common.c | 2 +-
app/test-pipeline/pipeline_acl.c | 16 +-
app/test-pipeline/pipeline_hash.c | 12 +-
app/test-pmd/cmdline.c | 90 +++---
app/test-pmd/cmdline_flow.c | 86 +++---
app/test-pmd/config.c | 34 +--
app/test-pmd/csumonly.c | 160 +++++-----
app/test-pmd/flowgen.c | 30 +-
app/test-pmd/icmpecho.c | 120 ++++----
app/test-pmd/ieee1588fwd.c | 18 +-
app/test-pmd/macfwd.c | 12 +-
app/test-pmd/macswap.h | 12 +-
app/test-pmd/macswap_common.h | 4 +-
app/test-pmd/macswap_neon.h | 12 +-
app/test-pmd/macswap_sse.h | 12 +-
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c | 22 +-
app/test-pmd/testpmd.h | 30 +-
app/test-pmd/txonly.c | 44 +--
app/test-pmd/util.c | 34 +--
app/test/packet_burst_generator.c | 126 ++++----
app/test/packet_burst_generator.h | 26 +-
app/test/test_acl.c | 8 +-
app/test/test_acl.h | 122 ++++----
app/test/test_cmdline_etheraddr.c | 16 +-
app/test/test_efd.c | 20 +-
app/test/test_event_eth_rx_adapter.c | 2 +-
app/test/test_event_eth_tx_adapter.c | 2 +-
app/test/test_flow_classify.c | 68 ++---
app/test/test_hash.c | 20 +-
app/test/test_ipsec.c | 12 +-
app/test/test_link_bonding.c | 284 +++++++++---------
app/test/test_link_bonding_mode4.c | 116 ++++----
app/test/test_link_bonding_rssconf.c | 6 +-
app/test/test_lpm.c | 76 ++---
app/test/test_lpm_perf.c | 10 +-
app/test/test_member.c | 20 +-
app/test/test_pmd_perf.c | 20 +-
app/test/test_sched.c | 20 +-
app/test/test_table_acl.c | 8 +-
app/test/test_thash.c | 12 +-
app/test/virtual_pmd.c | 6 +-
app/test/virtual_pmd.h | 2 +-
doc/guides/nics/kni.rst | 2 +-
doc/guides/prog_guide/bbdev.rst | 6 +-
.../prog_guide/packet_classif_access_ctrl.rst | 18 +-
doc/guides/prog_guide/rte_flow.rst | 4 +-
doc/guides/sample_app_ug/flow_classify.rst | 28 +-
doc/guides/sample_app_ug/flow_filtering.rst | 6 +-
doc/guides/sample_app_ug/ip_frag.rst | 16 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 16 +-
doc/guides/sample_app_ug/ipv4_multicast.rst | 16 +-
doc/guides/sample_app_ug/l2_forward_job_stats.rst | 6 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 6 +-
doc/guides/sample_app_ug/l3_forward.rst | 12 +-
doc/guides/sample_app_ug/link_status_intr.rst | 6 +-
doc/guides/sample_app_ug/ptpclient.rst | 6 +-
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/server_node_efd.rst | 12 +-
doc/guides/sample_app_ug/skeleton.rst | 4 +-
doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 4 +-
drivers/bus/dpaa/base/fman/fman.c | 2 +-
drivers/bus/dpaa/base/fman/fman_hw.c | 2 +-
drivers/bus/dpaa/include/fman.h | 2 +-
drivers/bus/dpaa/include/netcfg.h | 4 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +-
drivers/net/ark/ark_ethdev.c | 16 +-
drivers/net/ark/ark_ext.h | 4 +-
drivers/net/ark/ark_global.h | 4 +-
drivers/net/atlantic/atl_ethdev.c | 20 +-
drivers/net/atlantic/hw_atl/hw_atl_utils.c | 8 +-
drivers/net/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 +-
drivers/net/avp/avp_ethdev.c | 20 +-
drivers/net/avp/rte_avp_common.h | 2 +-
drivers/net/axgbe/axgbe_dev.c | 4 +-
drivers/net/axgbe/axgbe_ethdev.c | 10 +-
drivers/net/axgbe/axgbe_ethdev.h | 4 +-
drivers/net/axgbe/axgbe_rxtx.c | 2 +-
drivers/net/bnx2x/bnx2x.c | 16 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +-
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/bnx2x/bnx2x_vfpf.c | 8 +-
drivers/net/bnx2x/bnx2x_vfpf.h | 2 +-
drivers/net/bnx2x/ecore_sp.h | 2 +-
drivers/net/bnxt/bnxt.h | 4 +-
drivers/net/bnxt/bnxt_ethdev.c | 70 ++---
drivers/net/bnxt/bnxt_filter.c | 4 +-
drivers/net/bnxt/bnxt_filter.h | 8 +-
drivers/net/bnxt/bnxt_flow.c | 26 +-
drivers/net/bnxt/bnxt_hwrm.c | 40 +--
drivers/net/bnxt/bnxt_hwrm.h | 2 +-
drivers/net/bnxt/bnxt_ring.c | 8 +-
drivers/net/bnxt/bnxt_rxq.c | 2 +-
drivers/net/bnxt/bnxt_rxr.c | 2 +-
drivers/net/bnxt/bnxt_vnic.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 14 +-
drivers/net/bnxt/rte_pmd_bnxt.h | 4 +-
drivers/net/bonding/rte_eth_bond.h | 2 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 28 +-
drivers/net/bonding/rte_eth_bond_8023ad.h | 10 +-
drivers/net/bonding/rte_eth_bond_8023ad_private.h | 2 +-
drivers/net/bonding/rte_eth_bond_alb.c | 78 ++---
drivers/net/bonding/rte_eth_bond_alb.h | 10 +-
drivers/net/bonding/rte_eth_bond_api.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 194 ++++++-------
drivers/net/bonding/rte_eth_bond_private.h | 6 +-
drivers/net/cxgbe/base/adapter.h | 6 +-
drivers/net/cxgbe/base/t4_hw.c | 8 +-
drivers/net/cxgbe/cxgbe.h | 4 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 14 +-
drivers/net/cxgbe/cxgbe_filter.h | 2 +-
drivers/net/cxgbe/cxgbe_flow.c | 10 +-
drivers/net/cxgbe/cxgbe_main.c | 4 +-
drivers/net/cxgbe/cxgbe_pfvf.h | 2 +-
drivers/net/cxgbe/cxgbevf_main.c | 2 +-
drivers/net/cxgbe/l2t.c | 8 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.c | 14 +-
drivers/net/cxgbe/mps_tcam.h | 4 +-
drivers/net/cxgbe/sge.c | 8 +-
drivers/net/dpaa/dpaa_ethdev.c | 20 +-
drivers/net/dpaa/dpaa_rxtx.c | 22 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 36 +--
drivers/net/dpaa2/dpaa2_flow.c | 18 +-
drivers/net/e1000/e1000_ethdev.h | 4 +-
drivers/net/e1000/em_ethdev.c | 34 +--
drivers/net/e1000/em_rxtx.c | 22 +-
drivers/net/e1000/igb_ethdev.c | 70 ++---
drivers/net/e1000/igb_flow.c | 12 +-
drivers/net/e1000/igb_pf.c | 16 +-
drivers/net/e1000/igb_rxtx.c | 18 +-
drivers/net/ena/ena_ethdev.c | 16 +-
drivers/net/ena/ena_ethdev.h | 2 +-
drivers/net/enetc/base/enetc_hw.h | 4 +-
drivers/net/enetc/enetc_ethdev.c | 6 +-
drivers/net/enic/enic.h | 4 +-
drivers/net/enic/enic_clsf.c | 40 +--
drivers/net/enic/enic_ethdev.c | 28 +-
drivers/net/enic/enic_flow.c | 106 +++----
drivers/net/enic/enic_main.c | 4 +-
drivers/net/enic/enic_res.c | 4 +-
drivers/net/failsafe/failsafe.c | 6 +-
drivers/net/failsafe/failsafe_args.c | 4 +-
drivers/net/failsafe/failsafe_ether.c | 6 +-
drivers/net/failsafe/failsafe_ops.c | 6 +-
drivers/net/failsafe/failsafe_private.h | 4 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 18 +-
drivers/net/i40e/base/i40e_adminq_cmd.h | 4 +-
drivers/net/i40e/base/i40e_common.c | 12 +-
drivers/net/i40e/base/i40e_prototype.h | 4 +-
drivers/net/i40e/i40e_ethdev.c | 136 ++++-----
drivers/net/i40e/i40e_ethdev.h | 22 +-
drivers/net/i40e/i40e_ethdev_vf.c | 62 ++--
drivers/net/i40e/i40e_fdir.c | 126 ++++----
drivers/net/i40e/i40e_flow.c | 58 ++--
drivers/net/i40e/i40e_pf.c | 18 +-
drivers/net/i40e/i40e_rxtx.c | 28 +-
drivers/net/i40e/i40e_vf_representor.c | 2 +-
drivers/net/i40e/rte_pmd_i40e.c | 30 +-
drivers/net/i40e/rte_pmd_i40e.h | 8 +-
drivers/net/iavf/base/iavf_adminq_cmd.h | 4 +-
drivers/net/iavf/base/iavf_common.c | 12 +-
drivers/net/iavf/base/iavf_prototype.h | 4 +-
drivers/net/iavf/iavf.h | 4 +-
drivers/net/iavf/iavf_ethdev.c | 50 ++--
drivers/net/iavf/iavf_rxtx.c | 14 +-
drivers/net/iavf/iavf_vchnl.c | 8 +-
drivers/net/ice/ice_ethdev.c | 62 ++--
drivers/net/ice/ice_ethdev.h | 4 +-
drivers/net/ice/ice_rxtx.c | 28 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 92 +++---
drivers/net/ixgbe/ixgbe_ethdev.h | 4 +-
drivers/net/ixgbe/ixgbe_flow.c | 22 +-
drivers/net/ixgbe/ixgbe_pf.c | 14 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +-
drivers/net/ixgbe/ixgbe_vf_representor.c | 4 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 10 +-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 2 +-
drivers/net/kni/rte_eth_kni.c | 6 +-
drivers/net/liquidio/lio_ethdev.c | 22 +-
drivers/net/mlx4/mlx4.c | 4 +-
drivers/net/mlx4/mlx4.h | 8 +-
drivers/net/mlx4/mlx4_ethdev.c | 8 +-
drivers/net/mlx4/mlx4_flow.c | 14 +-
drivers/net/mlx4/mlx4_rxtx.c | 2 +-
drivers/net/mlx5/mlx5.c | 4 +-
drivers/net/mlx5/mlx5.h | 14 +-
drivers/net/mlx5/mlx5_flow.c | 22 +-
drivers/net/mlx5/mlx5_flow_dv.c | 44 +--
drivers/net/mlx5/mlx5_flow_tcf.c | 66 ++---
drivers/net/mlx5/mlx5_flow_verbs.c | 26 +-
drivers/net/mlx5/mlx5_mac.c | 18 +-
drivers/net/mlx5/mlx5_nl.c | 28 +-
drivers/net/mlx5/mlx5_rxtx.c | 6 +-
drivers/net/mlx5/mlx5_rxtx.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 8 +-
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 10 +-
drivers/net/mlx5/mlx5_trigger.c | 6 +-
drivers/net/mvneta/mvneta_ethdev.c | 22 +-
drivers/net/mvneta/mvneta_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 22 +-
drivers/net/mvpp2/mrvl_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_flow.c | 4 +-
drivers/net/netvsc/hn_ethdev.c | 4 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rndis.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 12 +-
drivers/net/netvsc/hn_var.h | 4 +-
drivers/net/netvsc/hn_vf.c | 8 +-
drivers/net/nfp/nfp_net.c | 20 +-
drivers/net/nfp/nfp_net_pmd.h | 2 +-
drivers/net/null/rte_eth_null.c | 6 +-
drivers/net/octeontx/octeontx_ethdev.c | 8 +-
drivers/net/octeontx/octeontx_ethdev.h | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 22 +-
drivers/net/qede/base/bcm_osal.h | 2 +-
drivers/net/qede/base/ecore_dev.c | 4 +-
drivers/net/qede/qede_ethdev.c | 58 ++--
drivers/net/qede/qede_ethdev.h | 6 +-
drivers/net/qede/qede_filter.c | 66 ++---
drivers/net/qede/qede_if.h | 4 +-
drivers/net/qede/qede_main.c | 6 +-
drivers/net/qede/qede_rxtx.c | 32 +-
drivers/net/qede/qede_rxtx.h | 2 +-
drivers/net/ring/rte_eth_ring.c | 4 +-
drivers/net/sfc/sfc.h | 2 +-
drivers/net/sfc/sfc_ef10_tx.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 20 +-
drivers/net/sfc/sfc_flow.c | 12 +-
drivers/net/sfc/sfc_port.c | 8 +-
drivers/net/sfc/sfc_tso.c | 4 +-
drivers/net/sfc/sfc_tso.h | 4 +-
drivers/net/softnic/parser.c | 18 +-
drivers/net/softnic/parser.h | 2 +-
drivers/net/softnic/rte_eth_softnic.c | 2 +-
drivers/net/softnic/rte_eth_softnic_flow.c | 4 +-
drivers/net/softnic/rte_eth_softnic_pipeline.c | 40 +--
drivers/net/szedata2/rte_eth_szedata2.c | 8 +-
drivers/net/tap/rte_eth_tap.c | 60 ++--
drivers/net/tap/rte_eth_tap.h | 2 +-
drivers/net/tap/tap_bpf_program.c | 14 +-
drivers/net/tap/tap_flow.c | 12 +-
drivers/net/thunderx/base/nicvf_mbox.c | 4 +-
drivers/net/thunderx/base/nicvf_plat.h | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 18 +-
drivers/net/thunderx/nicvf_struct.h | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 16 +-
drivers/net/vhost/rte_eth_vhost.c | 12 +-
drivers/net/virtio/virtio_ethdev.c | 72 ++---
drivers/net/virtio/virtio_pci.h | 4 +-
drivers/net/virtio/virtio_rxtx.c | 32 +-
drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 2 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 6 +-
drivers/net/virtio/virtio_user/virtio_user_dev.h | 2 +-
drivers/net/virtio/virtio_user_ethdev.c | 8 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +-
drivers/net/vmxnet3/vmxnet3_ethdev.h | 2 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 44 +--
examples/bbdev_app/main.c | 40 +--
examples/bond/main.c | 78 ++---
examples/distributor/main.c | 4 +-
examples/ethtool/ethtool-app/ethapp.c | 8 +-
examples/ethtool/ethtool-app/main.c | 10 +-
examples/ethtool/lib/rte_ethtool.c | 8 +-
examples/ethtool/lib/rte_ethtool.h | 6 +-
examples/eventdev_pipeline/main.c | 4 +-
examples/eventdev_pipeline/pipeline_common.h | 10 +-
examples/flow_classify/flow_classify.c | 30 +-
examples/flow_filtering/main.c | 10 +-
examples/ip_fragmentation/main.c | 64 ++--
examples/ip_pipeline/cli.c | 4 +-
examples/ip_pipeline/kni.c | 2 +-
examples/ip_pipeline/parser.c | 18 +-
examples/ip_pipeline/parser.h | 2 +-
examples/ip_pipeline/pipeline.c | 40 +--
examples/ip_reassembly/main.c | 50 ++--
examples/ipsec-secgw/esp.c | 42 +--
examples/ipsec-secgw/ipsec-secgw.c | 42 +--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/parser.c | 4 +-
examples/ipsec-secgw/sa.c | 16 +-
examples/ipv4_multicast/main.c | 58 ++--
examples/kni/main.c | 14 +-
examples/l2fwd-cat/l2fwd-cat.c | 4 +-
examples/l2fwd-crypto/main.c | 26 +-
examples/l2fwd-jobstats/main.c | 8 +-
examples/l2fwd-keepalive/main.c | 8 +-
examples/l2fwd/main.c | 8 +-
examples/l3fwd-acl/main.c | 102 +++----
examples/l3fwd-power/main.c | 100 +++----
examples/l3fwd-vf/main.c | 68 ++---
examples/l3fwd/l3fwd.h | 8 +-
examples/l3fwd/l3fwd_altivec.h | 14 +-
examples/l3fwd/l3fwd_common.h | 4 +-
examples/l3fwd/l3fwd_em.c | 44 +--
examples/l3fwd/l3fwd_em.h | 20 +-
examples/l3fwd/l3fwd_em_hlm.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_neon.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_sse.h | 16 +-
examples/l3fwd/l3fwd_em_sequential.h | 16 +-
examples/l3fwd/l3fwd_lpm.c | 50 ++--
examples/l3fwd/l3fwd_lpm.h | 20 +-
examples/l3fwd/l3fwd_lpm_altivec.h | 20 +-
examples/l3fwd/l3fwd_lpm_neon.h | 30 +-
examples/l3fwd/l3fwd_lpm_sse.h | 20 +-
examples/l3fwd/l3fwd_neon.h | 14 +-
examples/l3fwd/l3fwd_sse.h | 14 +-
examples/l3fwd/main.c | 20 +-
examples/link_status_interrupt/main.c | 8 +-
examples/load_balancer/runtime.c | 6 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/packet_ordering/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 322 ++++++++++-----------
examples/ptpclient/ptpclient.c | 32 +-
examples/qos_meter/main.c | 4 +-
examples/qos_sched/init.c | 2 +-
examples/quota_watermark/qw/main.c | 8 +-
examples/rxtx_callbacks/main.c | 4 +-
examples/server_node_efd/node/node.c | 6 +-
examples/server_node_efd/server/main.c | 8 +-
examples/skeleton/basicfwd.c | 4 +-
examples/tep_termination/main.c | 2 +-
examples/tep_termination/main.h | 2 +-
examples/tep_termination/vxlan.c | 108 +++----
examples/tep_termination/vxlan.h | 8 +-
examples/tep_termination/vxlan_setup.c | 30 +-
examples/tep_termination/vxlan_setup.h | 2 +-
examples/vhost/main.c | 40 +--
examples/vhost/main.h | 2 +-
examples/vm_power_manager/channel_monitor.c | 12 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/main.c | 6 +-
examples/vmdq/main.c | 12 +-
examples/vmdq_dcb/main.c | 12 +-
lib/librte_ethdev/rte_class_eth.c | 4 +-
lib/librte_ethdev/rte_eth_ctrl.h | 12 +-
lib/librte_ethdev/rte_ethdev.c | 58 ++--
lib/librte_ethdev/rte_ethdev.h | 14 +-
lib/librte_ethdev/rte_ethdev_core.h | 12 +-
lib/librte_ethdev/rte_flow.h | 32 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 32 +-
lib/librte_gro/gro_tcp4.c | 26 +-
lib/librte_gro/gro_tcp4.h | 22 +-
lib/librte_gro/gro_vxlan_tcp4.c | 64 ++--
lib/librte_gro/gro_vxlan_tcp4.h | 6 +-
lib/librte_gso/gso_common.h | 16 +-
lib/librte_gso/gso_tcp4.c | 12 +-
lib/librte_gso/gso_tunnel_tcp4.c | 14 +-
lib/librte_gso/gso_udp4.c | 8 +-
lib/librte_gso/rte_gso.h | 8 +-
lib/librte_hash/rte_thash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 12 +-
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 42 +--
lib/librte_ip_frag/rte_ipv4_reassembly.c | 14 +-
lib/librte_ip_frag/rte_ipv6_fragmentation.c | 26 +-
lib/librte_ip_frag/rte_ipv6_reassembly.c | 6 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/esp_inb.c | 10 +-
lib/librte_ipsec/esp_outb.c | 8 +-
lib/librte_ipsec/iph.h | 8 +-
lib/librte_ipsec/sa.c | 8 +-
lib/librte_kni/rte_kni.c | 4 +-
lib/librte_kni/rte_kni.h | 2 +-
lib/librte_net/rte_arp.c | 32 +-
lib/librte_net/rte_arp.h | 36 +--
lib/librte_net/rte_esp.h | 2 +-
lib/librte_net/rte_ether.h | 182 ++++++------
lib/librte_net/rte_gre.h | 2 +-
lib/librte_net/rte_icmp.h | 6 +-
lib/librte_net/rte_ip.h | 72 ++---
lib/librte_net/rte_net.c | 94 +++---
lib/librte_net/rte_net.h | 22 +-
lib/librte_net/rte_sctp.h | 2 +-
lib/librte_net/rte_tcp.h | 2 +-
lib/librte_net/rte_udp.h | 2 +-
lib/librte_pipeline/rte_table_action.c | 224 +++++++-------
lib/librte_pipeline/rte_table_action.h | 4 +-
lib/librte_port/rte_port_ras.c | 8 +-
lib/librte_port/rte_port_source_sink.c | 6 +-
lib/librte_vhost/vhost.h | 2 +-
lib/librte_vhost/virtio_net.c | 42 +--
388 files changed, 4145 insertions(+), 4145 deletions(-)
--
2.11.0
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [RFC v2 00/14] prefix network structures
@ 2019-04-10 8:32 1% ` Olivier Matz
2019-04-10 8:32 1% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-04-10 8:32 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit
This RFC targets 19.08.
The rte_net headers conflict with the libc headers, because
some definitions are duplicated, sometimes with few differences.
This RFC adds the rte_ (or RTE_) prefix to all structures, functions
and defines in rte_net library. This is a big changeset, that will
break the API of many functions, but not the ABI.
This was discussed in [1], and recently requested by the techboard [2].
v2:
* rebase on top of v19.05-rc1
[1] http://mails.dpdk.org/archives/dev/2018-January/087384.html
[2] http://mails.dpdk.org/archives/dev/2019-February/125033.html
Olivier Matz (14):
net: add rte prefix to arp structures
net: add rte prefix to arp defines
net: add rte prefix to ether structures
net: add rte prefix to ether functions
net: add rte prefix to ether defines
net: add rte prefix to esp structure
net: add rte prefix to gre structure
net: add rte prefix to icmp structure
net: add rte prefix to icmp defines
net: add rte prefix to ip structure
net: add rte prefix to ip defines
net: add rte prefix to sctp structure
net: add rte prefix to tcp structure
net: add rte prefix to udp structure
app/pdump/main.c | 2 +-
app/test-acl/main.c | 2 +-
app/test-eventdev/test_perf_common.c | 2 +-
app/test-eventdev/test_pipeline_common.c | 2 +-
app/test-pipeline/pipeline_acl.c | 16 +-
app/test-pipeline/pipeline_hash.c | 12 +-
app/test-pmd/cmdline.c | 90 +++---
app/test-pmd/cmdline_flow.c | 86 +++---
app/test-pmd/config.c | 34 +--
app/test-pmd/csumonly.c | 160 +++++-----
app/test-pmd/flowgen.c | 30 +-
app/test-pmd/icmpecho.c | 120 ++++----
app/test-pmd/ieee1588fwd.c | 18 +-
app/test-pmd/macfwd.c | 12 +-
app/test-pmd/macswap.h | 12 +-
app/test-pmd/macswap_common.h | 4 +-
app/test-pmd/macswap_neon.h | 12 +-
app/test-pmd/macswap_sse.h | 12 +-
app/test-pmd/parameters.c | 6 +-
app/test-pmd/testpmd.c | 22 +-
app/test-pmd/testpmd.h | 30 +-
app/test-pmd/txonly.c | 44 +--
app/test-pmd/util.c | 34 +--
app/test/packet_burst_generator.c | 126 ++++----
app/test/packet_burst_generator.h | 26 +-
app/test/test_acl.c | 8 +-
app/test/test_acl.h | 122 ++++----
app/test/test_cmdline_etheraddr.c | 16 +-
app/test/test_efd.c | 20 +-
app/test/test_event_eth_rx_adapter.c | 2 +-
app/test/test_event_eth_tx_adapter.c | 2 +-
app/test/test_flow_classify.c | 68 ++---
app/test/test_hash.c | 20 +-
app/test/test_ipsec.c | 12 +-
app/test/test_link_bonding.c | 284 +++++++++---------
app/test/test_link_bonding_mode4.c | 116 ++++----
app/test/test_link_bonding_rssconf.c | 6 +-
app/test/test_lpm.c | 76 ++---
app/test/test_lpm_perf.c | 10 +-
app/test/test_member.c | 20 +-
app/test/test_pmd_perf.c | 20 +-
app/test/test_sched.c | 20 +-
app/test/test_table_acl.c | 8 +-
app/test/test_thash.c | 12 +-
app/test/virtual_pmd.c | 6 +-
app/test/virtual_pmd.h | 2 +-
doc/guides/nics/kni.rst | 2 +-
doc/guides/prog_guide/bbdev.rst | 6 +-
.../prog_guide/packet_classif_access_ctrl.rst | 18 +-
doc/guides/prog_guide/rte_flow.rst | 4 +-
doc/guides/sample_app_ug/flow_classify.rst | 28 +-
doc/guides/sample_app_ug/flow_filtering.rst | 6 +-
doc/guides/sample_app_ug/ip_frag.rst | 16 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 16 +-
doc/guides/sample_app_ug/ipv4_multicast.rst | 16 +-
doc/guides/sample_app_ug/l2_forward_job_stats.rst | 6 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 6 +-
doc/guides/sample_app_ug/l3_forward.rst | 12 +-
doc/guides/sample_app_ug/link_status_intr.rst | 6 +-
doc/guides/sample_app_ug/ptpclient.rst | 6 +-
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/server_node_efd.rst | 12 +-
doc/guides/sample_app_ug/skeleton.rst | 4 +-
doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 4 +-
drivers/bus/dpaa/base/fman/fman.c | 2 +-
drivers/bus/dpaa/base/fman/fman_hw.c | 2 +-
drivers/bus/dpaa/include/fman.h | 2 +-
drivers/bus/dpaa/include/netcfg.h | 4 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +-
drivers/net/ark/ark_ethdev.c | 16 +-
drivers/net/ark/ark_ext.h | 4 +-
drivers/net/ark/ark_global.h | 4 +-
drivers/net/atlantic/atl_ethdev.c | 20 +-
drivers/net/atlantic/hw_atl/hw_atl_utils.c | 8 +-
drivers/net/atlantic/hw_atl/hw_atl_utils_fw2x.c | 4 +-
drivers/net/avp/avp_ethdev.c | 20 +-
drivers/net/avp/rte_avp_common.h | 2 +-
drivers/net/axgbe/axgbe_dev.c | 4 +-
drivers/net/axgbe/axgbe_ethdev.c | 10 +-
drivers/net/axgbe/axgbe_ethdev.h | 4 +-
drivers/net/axgbe/axgbe_rxtx.c | 2 +-
drivers/net/bnx2x/bnx2x.c | 16 +-
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +-
drivers/net/bnx2x/bnx2x_ethdev.h | 2 +-
drivers/net/bnx2x/bnx2x_vfpf.c | 8 +-
drivers/net/bnx2x/bnx2x_vfpf.h | 2 +-
drivers/net/bnx2x/ecore_sp.h | 2 +-
drivers/net/bnxt/bnxt.h | 4 +-
drivers/net/bnxt/bnxt_ethdev.c | 70 ++---
drivers/net/bnxt/bnxt_filter.c | 4 +-
drivers/net/bnxt/bnxt_filter.h | 8 +-
drivers/net/bnxt/bnxt_flow.c | 26 +-
drivers/net/bnxt/bnxt_hwrm.c | 40 +--
drivers/net/bnxt/bnxt_hwrm.h | 2 +-
drivers/net/bnxt/bnxt_ring.c | 8 +-
drivers/net/bnxt/bnxt_rxq.c | 2 +-
drivers/net/bnxt/bnxt_rxr.c | 2 +-
drivers/net/bnxt/bnxt_vnic.c | 2 +-
drivers/net/bnxt/rte_pmd_bnxt.c | 14 +-
drivers/net/bnxt/rte_pmd_bnxt.h | 4 +-
drivers/net/bonding/rte_eth_bond.h | 2 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 28 +-
drivers/net/bonding/rte_eth_bond_8023ad.h | 10 +-
drivers/net/bonding/rte_eth_bond_8023ad_private.h | 2 +-
drivers/net/bonding/rte_eth_bond_alb.c | 78 ++---
drivers/net/bonding/rte_eth_bond_alb.h | 10 +-
drivers/net/bonding/rte_eth_bond_api.c | 2 +-
drivers/net/bonding/rte_eth_bond_args.c | 2 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 194 ++++++-------
drivers/net/bonding/rte_eth_bond_private.h | 6 +-
drivers/net/cxgbe/base/adapter.h | 6 +-
drivers/net/cxgbe/base/t4_hw.c | 8 +-
drivers/net/cxgbe/cxgbe.h | 4 +-
drivers/net/cxgbe/cxgbe_ethdev.c | 14 +-
drivers/net/cxgbe/cxgbe_filter.h | 2 +-
drivers/net/cxgbe/cxgbe_flow.c | 10 +-
drivers/net/cxgbe/cxgbe_main.c | 4 +-
drivers/net/cxgbe/cxgbe_pfvf.h | 2 +-
drivers/net/cxgbe/cxgbevf_main.c | 2 +-
drivers/net/cxgbe/l2t.c | 8 +-
drivers/net/cxgbe/l2t.h | 2 +-
drivers/net/cxgbe/mps_tcam.c | 14 +-
drivers/net/cxgbe/mps_tcam.h | 4 +-
drivers/net/cxgbe/sge.c | 8 +-
drivers/net/dpaa/dpaa_ethdev.c | 20 +-
drivers/net/dpaa/dpaa_rxtx.c | 22 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 36 +--
drivers/net/dpaa2/dpaa2_flow.c | 18 +-
drivers/net/e1000/e1000_ethdev.h | 4 +-
drivers/net/e1000/em_ethdev.c | 34 +--
drivers/net/e1000/em_rxtx.c | 22 +-
drivers/net/e1000/igb_ethdev.c | 70 ++---
drivers/net/e1000/igb_flow.c | 12 +-
drivers/net/e1000/igb_pf.c | 16 +-
drivers/net/e1000/igb_rxtx.c | 18 +-
drivers/net/ena/ena_ethdev.c | 16 +-
drivers/net/ena/ena_ethdev.h | 2 +-
drivers/net/enetc/base/enetc_hw.h | 4 +-
drivers/net/enetc/enetc_ethdev.c | 6 +-
drivers/net/enic/enic.h | 4 +-
drivers/net/enic/enic_clsf.c | 40 +--
drivers/net/enic/enic_ethdev.c | 28 +-
drivers/net/enic/enic_flow.c | 106 +++----
drivers/net/enic/enic_main.c | 4 +-
drivers/net/enic/enic_res.c | 4 +-
drivers/net/failsafe/failsafe.c | 6 +-
drivers/net/failsafe/failsafe_args.c | 4 +-
drivers/net/failsafe/failsafe_ether.c | 6 +-
drivers/net/failsafe/failsafe_ops.c | 6 +-
drivers/net/failsafe/failsafe_private.h | 4 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_ethdev.c | 18 +-
drivers/net/i40e/base/i40e_adminq_cmd.h | 4 +-
drivers/net/i40e/base/i40e_common.c | 12 +-
drivers/net/i40e/base/i40e_prototype.h | 4 +-
drivers/net/i40e/i40e_ethdev.c | 136 ++++-----
drivers/net/i40e/i40e_ethdev.h | 22 +-
drivers/net/i40e/i40e_ethdev_vf.c | 62 ++--
drivers/net/i40e/i40e_fdir.c | 126 ++++----
drivers/net/i40e/i40e_flow.c | 58 ++--
drivers/net/i40e/i40e_pf.c | 18 +-
drivers/net/i40e/i40e_rxtx.c | 28 +-
drivers/net/i40e/i40e_vf_representor.c | 2 +-
drivers/net/i40e/rte_pmd_i40e.c | 30 +-
drivers/net/i40e/rte_pmd_i40e.h | 8 +-
drivers/net/iavf/base/iavf_adminq_cmd.h | 4 +-
drivers/net/iavf/base/iavf_common.c | 12 +-
drivers/net/iavf/base/iavf_prototype.h | 4 +-
drivers/net/iavf/iavf.h | 4 +-
drivers/net/iavf/iavf_ethdev.c | 50 ++--
drivers/net/iavf/iavf_rxtx.c | 14 +-
drivers/net/iavf/iavf_vchnl.c | 8 +-
drivers/net/ice/ice_ethdev.c | 62 ++--
drivers/net/ice/ice_ethdev.h | 4 +-
drivers/net/ice/ice_rxtx.c | 28 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 92 +++---
drivers/net/ixgbe/ixgbe_ethdev.h | 4 +-
drivers/net/ixgbe/ixgbe_flow.c | 22 +-
drivers/net/ixgbe/ixgbe_pf.c | 14 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 14 +-
drivers/net/ixgbe/ixgbe_vf_representor.c | 4 +-
drivers/net/ixgbe/rte_pmd_ixgbe.c | 10 +-
drivers/net/ixgbe/rte_pmd_ixgbe.h | 2 +-
drivers/net/kni/rte_eth_kni.c | 6 +-
drivers/net/liquidio/lio_ethdev.c | 22 +-
drivers/net/mlx4/mlx4.c | 4 +-
drivers/net/mlx4/mlx4.h | 8 +-
drivers/net/mlx4/mlx4_ethdev.c | 8 +-
drivers/net/mlx4/mlx4_flow.c | 14 +-
drivers/net/mlx4/mlx4_rxtx.c | 2 +-
drivers/net/mlx5/mlx5.c | 4 +-
drivers/net/mlx5/mlx5.h | 14 +-
drivers/net/mlx5/mlx5_flow.c | 22 +-
drivers/net/mlx5/mlx5_flow_dv.c | 44 +--
drivers/net/mlx5/mlx5_flow_tcf.c | 66 ++---
drivers/net/mlx5/mlx5_flow_verbs.c | 26 +-
drivers/net/mlx5/mlx5_mac.c | 18 +-
drivers/net/mlx5/mlx5_nl.c | 28 +-
drivers/net/mlx5/mlx5_rxtx.c | 6 +-
drivers/net/mlx5/mlx5_rxtx.h | 2 +-
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 8 +-
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 10 +-
drivers/net/mlx5/mlx5_trigger.c | 6 +-
drivers/net/mvneta/mvneta_ethdev.c | 22 +-
drivers/net/mvneta/mvneta_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_ethdev.c | 22 +-
drivers/net/mvpp2/mrvl_ethdev.h | 2 +-
drivers/net/mvpp2/mrvl_flow.c | 4 +-
drivers/net/netvsc/hn_ethdev.c | 4 +-
drivers/net/netvsc/hn_nvs.c | 2 +-
drivers/net/netvsc/hn_rndis.c | 2 +-
drivers/net/netvsc/hn_rxtx.c | 12 +-
drivers/net/netvsc/hn_var.h | 4 +-
drivers/net/netvsc/hn_vf.c | 8 +-
drivers/net/nfp/nfp_net.c | 20 +-
drivers/net/nfp/nfp_net_pmd.h | 2 +-
drivers/net/null/rte_eth_null.c | 6 +-
drivers/net/octeontx/octeontx_ethdev.c | 8 +-
drivers/net/octeontx/octeontx_ethdev.h | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 22 +-
drivers/net/qede/base/bcm_osal.h | 2 +-
drivers/net/qede/base/ecore_dev.c | 4 +-
drivers/net/qede/qede_ethdev.c | 58 ++--
drivers/net/qede/qede_ethdev.h | 6 +-
drivers/net/qede/qede_filter.c | 66 ++---
drivers/net/qede/qede_if.h | 4 +-
drivers/net/qede/qede_main.c | 6 +-
drivers/net/qede/qede_rxtx.c | 32 +-
drivers/net/qede/qede_rxtx.h | 2 +-
drivers/net/ring/rte_eth_ring.c | 4 +-
drivers/net/sfc/sfc.h | 2 +-
drivers/net/sfc/sfc_ef10_tx.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 20 +-
drivers/net/sfc/sfc_flow.c | 12 +-
drivers/net/sfc/sfc_port.c | 8 +-
drivers/net/sfc/sfc_tso.c | 4 +-
drivers/net/sfc/sfc_tso.h | 4 +-
drivers/net/softnic/parser.c | 18 +-
drivers/net/softnic/parser.h | 2 +-
drivers/net/softnic/rte_eth_softnic.c | 2 +-
drivers/net/softnic/rte_eth_softnic_flow.c | 4 +-
drivers/net/softnic/rte_eth_softnic_pipeline.c | 40 +--
drivers/net/szedata2/rte_eth_szedata2.c | 8 +-
drivers/net/tap/rte_eth_tap.c | 60 ++--
drivers/net/tap/rte_eth_tap.h | 2 +-
drivers/net/tap/tap_bpf_program.c | 14 +-
drivers/net/tap/tap_flow.c | 12 +-
drivers/net/thunderx/base/nicvf_mbox.c | 4 +-
drivers/net/thunderx/base/nicvf_plat.h | 2 +-
drivers/net/thunderx/nicvf_ethdev.c | 18 +-
drivers/net/thunderx/nicvf_struct.h | 2 +-
drivers/net/vdev_netvsc/vdev_netvsc.c | 16 +-
drivers/net/vhost/rte_eth_vhost.c | 12 +-
drivers/net/virtio/virtio_ethdev.c | 72 ++---
drivers/net/virtio/virtio_pci.h | 4 +-
drivers/net/virtio/virtio_rxtx.c | 32 +-
drivers/net/virtio/virtio_user/vhost_kernel_tap.c | 2 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 6 +-
drivers/net/virtio/virtio_user/virtio_user_dev.h | 2 +-
drivers/net/virtio/virtio_user_ethdev.c | 8 +-
drivers/net/virtio/virtqueue.h | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 12 +-
drivers/net/vmxnet3/vmxnet3_ethdev.h | 2 +-
drivers/net/vmxnet3/vmxnet3_rxtx.c | 44 +--
examples/bbdev_app/main.c | 40 +--
examples/bond/main.c | 78 ++---
examples/distributor/main.c | 4 +-
examples/ethtool/ethtool-app/ethapp.c | 8 +-
examples/ethtool/ethtool-app/main.c | 10 +-
examples/ethtool/lib/rte_ethtool.c | 8 +-
examples/ethtool/lib/rte_ethtool.h | 6 +-
examples/eventdev_pipeline/main.c | 4 +-
examples/eventdev_pipeline/pipeline_common.h | 10 +-
examples/flow_classify/flow_classify.c | 30 +-
examples/flow_filtering/main.c | 10 +-
examples/ip_fragmentation/main.c | 64 ++--
examples/ip_pipeline/cli.c | 4 +-
examples/ip_pipeline/kni.c | 2 +-
examples/ip_pipeline/parser.c | 18 +-
examples/ip_pipeline/parser.h | 2 +-
examples/ip_pipeline/pipeline.c | 40 +--
examples/ip_reassembly/main.c | 50 ++--
examples/ipsec-secgw/esp.c | 42 +--
examples/ipsec-secgw/ipsec-secgw.c | 42 +--
examples/ipsec-secgw/ipsec.h | 2 +-
examples/ipsec-secgw/parser.c | 4 +-
examples/ipsec-secgw/sa.c | 16 +-
examples/ipv4_multicast/main.c | 58 ++--
examples/kni/main.c | 14 +-
examples/l2fwd-cat/l2fwd-cat.c | 4 +-
examples/l2fwd-crypto/main.c | 26 +-
examples/l2fwd-jobstats/main.c | 8 +-
examples/l2fwd-keepalive/main.c | 8 +-
examples/l2fwd/main.c | 8 +-
examples/l3fwd-acl/main.c | 102 +++----
examples/l3fwd-power/main.c | 100 +++----
examples/l3fwd-vf/main.c | 68 ++---
examples/l3fwd/l3fwd.h | 8 +-
examples/l3fwd/l3fwd_altivec.h | 14 +-
examples/l3fwd/l3fwd_common.h | 4 +-
examples/l3fwd/l3fwd_em.c | 44 +--
examples/l3fwd/l3fwd_em.h | 20 +-
examples/l3fwd/l3fwd_em_hlm.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_neon.h | 16 +-
examples/l3fwd/l3fwd_em_hlm_sse.h | 16 +-
examples/l3fwd/l3fwd_em_sequential.h | 16 +-
examples/l3fwd/l3fwd_lpm.c | 50 ++--
examples/l3fwd/l3fwd_lpm.h | 20 +-
examples/l3fwd/l3fwd_lpm_altivec.h | 20 +-
examples/l3fwd/l3fwd_lpm_neon.h | 30 +-
examples/l3fwd/l3fwd_lpm_sse.h | 20 +-
examples/l3fwd/l3fwd_neon.h | 14 +-
examples/l3fwd/l3fwd_sse.h | 14 +-
examples/l3fwd/main.c | 20 +-
examples/link_status_interrupt/main.c | 8 +-
examples/load_balancer/runtime.c | 6 +-
.../client_server_mp/mp_server/main.c | 2 +-
examples/packet_ordering/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 322 ++++++++++-----------
examples/ptpclient/ptpclient.c | 32 +-
examples/qos_meter/main.c | 4 +-
examples/qos_sched/init.c | 2 +-
examples/quota_watermark/qw/main.c | 8 +-
examples/rxtx_callbacks/main.c | 4 +-
examples/server_node_efd/node/node.c | 6 +-
examples/server_node_efd/server/main.c | 8 +-
examples/skeleton/basicfwd.c | 4 +-
examples/tep_termination/main.c | 2 +-
examples/tep_termination/main.h | 2 +-
examples/tep_termination/vxlan.c | 108 +++----
examples/tep_termination/vxlan.h | 8 +-
examples/tep_termination/vxlan_setup.c | 30 +-
examples/tep_termination/vxlan_setup.h | 2 +-
examples/vhost/main.c | 40 +--
examples/vhost/main.h | 2 +-
examples/vm_power_manager/channel_monitor.c | 12 +-
.../guest_cli/vm_power_cli_guest.c | 2 +-
examples/vm_power_manager/main.c | 6 +-
examples/vmdq/main.c | 12 +-
examples/vmdq_dcb/main.c | 12 +-
lib/librte_ethdev/rte_class_eth.c | 4 +-
lib/librte_ethdev/rte_eth_ctrl.h | 12 +-
lib/librte_ethdev/rte_ethdev.c | 58 ++--
lib/librte_ethdev/rte_ethdev.h | 14 +-
lib/librte_ethdev/rte_ethdev_core.h | 12 +-
lib/librte_ethdev/rte_flow.h | 32 +-
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 32 +-
lib/librte_gro/gro_tcp4.c | 26 +-
lib/librte_gro/gro_tcp4.h | 22 +-
lib/librte_gro/gro_vxlan_tcp4.c | 64 ++--
lib/librte_gro/gro_vxlan_tcp4.h | 6 +-
lib/librte_gso/gso_common.h | 16 +-
lib/librte_gso/gso_tcp4.c | 12 +-
lib/librte_gso/gso_tunnel_tcp4.c | 14 +-
lib/librte_gso/gso_udp4.c | 8 +-
lib/librte_gso/rte_gso.h | 8 +-
lib/librte_hash/rte_thash.h | 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 12 +-
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 42 +--
lib/librte_ip_frag/rte_ipv4_reassembly.c | 14 +-
lib/librte_ip_frag/rte_ipv6_fragmentation.c | 26 +-
lib/librte_ip_frag/rte_ipv6_reassembly.c | 6 +-
lib/librte_ipsec/crypto.h | 2 +-
lib/librte_ipsec/esp_inb.c | 10 +-
lib/librte_ipsec/esp_outb.c | 8 +-
lib/librte_ipsec/iph.h | 8 +-
lib/librte_ipsec/sa.c | 8 +-
lib/librte_kni/rte_kni.c | 4 +-
lib/librte_kni/rte_kni.h | 2 +-
lib/librte_net/rte_arp.c | 32 +-
lib/librte_net/rte_arp.h | 36 +--
lib/librte_net/rte_esp.h | 2 +-
lib/librte_net/rte_ether.h | 182 ++++++------
lib/librte_net/rte_gre.h | 2 +-
lib/librte_net/rte_icmp.h | 6 +-
lib/librte_net/rte_ip.h | 72 ++---
lib/librte_net/rte_net.c | 94 +++---
lib/librte_net/rte_net.h | 22 +-
lib/librte_net/rte_sctp.h | 2 +-
lib/librte_net/rte_tcp.h | 2 +-
lib/librte_net/rte_udp.h | 2 +-
lib/librte_pipeline/rte_table_action.c | 224 +++++++-------
lib/librte_pipeline/rte_table_action.h | 4 +-
lib/librte_port/rte_port_ras.c | 8 +-
lib/librte_port/rte_port_source_sink.c | 6 +-
lib/librte_vhost/vhost.h | 2 +-
lib/librte_vhost/virtio_net.c | 42 +--
388 files changed, 4145 insertions(+), 4145 deletions(-)
--
2.11.0
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-10 5:14 9% ` Honnappa Nagarahalli
@ 2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-10 5:14 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: Honnappa Nagarahalli, nd, nd
>
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received from
> a number of users of DPDK about ABI churn. In turn this feedback then
> prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> I guess the short story is that DPDK ABI hasn't really settled down as the
> project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive releases
> since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant re-integration
> and re-validation effort for new versions of DPDK. This effort from their
> perspective may not add value to their consuming project, particular if
> they are only updating to "stay current".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their projects
> to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS releases.
> A final removal notice will be published to the DPDK Mailing List, and if
> there are no strong objections only then an API may be removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
<snip>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
` (2 preceding siblings ...)
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
@ 2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
` (2 more replies)
3 siblings, 3 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-10 5:14 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard; +Cc: Honnappa Nagarahalli, nd, nd
>
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received from
> a number of users of DPDK about ABI churn. In turn this feedback then
> prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).
>
> I guess the short story is that DPDK ABI hasn't really settled down as the
> project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive releases
> since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant re-integration
> and re-validation effort for new versions of DPDK. This effort from their
> perspective may not add value to their consuming project, particular if
> they are only updating to "stay current".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their projects
> to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS releases.
> A final removal notice will be published to the DPDK Mailing List, and if
> there are no strong objections only then an API may be removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?
<snip>
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission
2019-04-09 17:36 4% [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission Rami Rosen
@ 2019-04-09 17:36 4% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-04-09 17:36 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, pablo.de.lara.guarch, akhil.goyal, john.mcnamara,
marko.kovacevic, Rami Rosen, stable
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for new network ethernet
PMDs it should be dpdk-next-net, and for new crypto PMDs
it should be dpdk-next-crypto. Though this may seem obvious, it
is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
doc/guides/contributing/patches.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..4dde8e724 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* If you add a new network PMD you should prepare the initial submission against dpdk-next-net repo.
+
+* If you add a new crypto PMD you should prepare the initial submission against dpdk-next-crypto repo.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission
@ 2019-04-09 17:36 4% Rami Rosen
2019-04-09 17:36 4% ` Rami Rosen
0 siblings, 1 reply; 200+ results
From: Rami Rosen @ 2019-04-09 17:36 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, pablo.de.lara.guarch, akhil.goyal, john.mcnamara,
marko.kovacevic, Rami Rosen, stable
This patch for DPDK Contributor's Guidelines indicates the repos
against which a new PMD should be prepared; for new network ethernet
PMDs it should be dpdk-next-net, and for new crypto PMDs
it should be dpdk-next-crypto. Though this may seem obvious, it
is not mentioned in DPDK documentation.
Cc: stable@dpdk.org
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
doc/guides/contributing/patches.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e623..4dde8e724 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -148,6 +148,10 @@ Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
+* If you add a new network PMD you should prepare the initial submission against dpdk-next-net repo.
+
+* If you add a new crypto PMD you should prepare the initial submission against dpdk-next-crypto repo.
+
* New external functions should be added to the local ``version.map`` file.
See the :doc:`Guidelines for ABI policy and versioning </contributing/versioning>`.
New external functions should also be added in alphabetical order.
--
2.19.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-09 9:42 4% ` Ray Kinsella
@ 2019-04-09 9:42 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-09 9:42 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 14:38, Burakov, Anatoly wrote:
> On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>>
>>
>> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> [SNIP]
>> [SNIP]
[SNIP]
>>
>
> Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
> specification" i don't mean there literally should be a document with a
> formal specification :)
When I hear the word specification I think encyclopedia-like stacks of
paper.
>
> Rather, i'm thinking more along the lines of, let's take a look at what
> we have, and think of ways we can reduce the amount of code and improve
> things without causing major inconveniences to great majority of users.
> As in, if we want to "break once more and then never again", then maybe
> instead of small incremental fixes here and there, we could actually do
> a more drastic change that keeps perhaps 90% users happy instead of
> 100%, but which reduces maintenance/validation effort from 100% down to
> 30%.
Agreed - all I would propose on top of this is that we give ourselves a
real deadline.
The DPDK API has been iterating since 2012 and while we can spare a few
more months to do tidy-up and get it right, we _do_ need to draw a line
in the sand at the same time.
>
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
> However, what *could* be realistic is to trim down complexity in EAL
> init and system code in general - to me (again, a concrete proposal!),
> that would be dropping igb_uio and supporting upstream kernel modules
> only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
> support and legacy mem modes, and perhaps bumping kernel version and
> removing some compatibility code as well. This would remove potentially
> thousands of lines of code and keep EAL cleaner and more maintainable:
> right now, we have two different hotplug mechanisms (UIO and VFIO), lots
> of different memory/interrupt modes, etc., for no reason that is readily
> apparent to me.
>
> So, as you can see, an effort to review and delineate what we want to
> support would be necessary if we want to ease the maintenance burden for
> either myself or anyone that inherits this code, as well as reducing the
> number of moving parts and, as a consequence, validation effort and
> amount of bugs. We can't simply do it in a random release "just
> because", but if we were to "break once more and then never again",
> perhaps this is something that could be considered.
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
THIS BREAKS ABI OF PREVIOUS RELEASES.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7687fe650f64..bc416bc8c19f 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index f6688327cad3..2f175f58ed42 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
@ 2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Most of these functions are not marked as experimental since
we want applications to convert over asap. The one exception is
the return_code, which is only used by some tests now and not
clear that it is even that useful.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 39 +++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 52 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index dbdf07a0c05b..4beea5705be7 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -222,6 +222,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..c3cf5a06269d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,45 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+int
+rte_lcore_return_code(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7687fe650f64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,8 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int
+rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +170,40 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int
+rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t
+rte_lcore_cpuset(unsigned int lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned int lcore_id);
/**
* Test if an lcore is enabled.
@@ -193,7 +215,7 @@ rte_lcore_to_socket_id(unsigned lcore_id)
* True if the given lcore is enabled; false otherwise.
*/
static inline int
-rte_lcore_is_enabled(unsigned lcore_id)
+rte_lcore_is_enabled(unsigned int lcore_id)
{
struct rte_config *cfg = rte_eal_get_configuration();
if (lcore_id >= RTE_MAX_LCORE)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..f6688327cad3 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -268,6 +268,16 @@ DPDK_18.11 {
} DPDK_18.08;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.08;
+
EXPERIMENTAL {
global:
@@ -329,6 +339,7 @@ EXPERIMENTAL {
rte_fbarray_set_free;
rte_fbarray_set_used;
rte_intr_callback_unregister_pending;
+ rte_lcore_return_code;
rte_log_register_type_and_pick_level;
rte_malloc_dump_heaps;
rte_malloc_heap_create;
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
@ 2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 0/5] make lcore_config internal
@ 2019-04-08 18:25 3% Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 18:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
This set of patches makes the lcore_config structure
internal to EAL and not part of the ABI. It supersedes
earlier RFC.
The first 4 would go into current release, and the
last would go into later release to make it fully
internal.
The same should be done for rte_config, but that
is more difficult.
Stephen Hemminger (5):
eal: add accessor functions for lcore_config
bus: use lcore accessor functions
examples/bond: use lcore accessor
app/test: use lcore accessor functions
eal: make lcore_config private
app/test/test_cryptodev.c | 2 +-
app/test/test_hash_readwrite_lf.c | 14 ++---
app/test/test_ring_perf.c | 22 ++++---
app/test/test_stack_perf.c | 20 +++---
doc/guides/rel_notes/release_19_05.rst | 7 +++
drivers/bus/dpaa/dpaa_bus.c | 6 +-
drivers/bus/fslmc/portal/dpaa2_hw_dpio.c | 4 +-
examples/bond/main.c | 4 +-
lib/librte_eal/common/eal_common_launch.c | 2 +
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++
lib/librte_eal/common/eal_private.h | 22 +++++++
lib/librte_eal/common/include/rte_lcore.h | 76 +++++++++++------------
lib/librte_eal/common/rte_service.c | 2 +
lib/librte_eal/rte_eal_version.map | 12 +++-
14 files changed, 159 insertions(+), 73 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:49 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:50 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
` (2 preceding siblings ...)
2019-04-08 15:49 4% ` Burakov, Anatoly
@ 2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-08 15:50 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 3:38 PM, David Marchand wrote:
>
>
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>
> <mailto:anatoly.burakov@intel.com
> <mailto:anatoly.burakov@intel.com>>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight",
> and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both.
> However,
> > realistically, i don't think dropping multiprocess is ever
> going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in
> our
> codebase (pdump, proc-info, etc.).
>
>
> Sorry, I don't want to highjack this thread, I can start a separate
> thread if people feel like it.
> If we go with stabilisation, we must be careful that we want to support
> the features.
>
> So about multiprocess, again, in those closed source projects you know
> of, what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is
> not that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
There are certainly things that we can do that can make some aspects of
multiprocess redundant. For example, for any kind of collectd-like
scenario, the Telemetry API (or Keith's DFS, or...) could conceivably
provide a better and more maintainable way of doing things.
Our multiprocess also makes it easier to write pipeline/load-balancing
type applications. To see an example, look at our
multiprocess/client-server example. This is demonstrating how, instead
of writing one big monolithic application, one could instead write a
number of smaller applications each doing their thing. It is of course
possible to do the same without multiprocess, as evidenced by our sample
applications such as load-balancer, distributor, ip-pipeline etc., but
it is arguably easier to implement *real* applications that way due to
separation of concerns and more focused codebase.
However, there are two use cases that i can think of that are either
hard or outright not possible without our multiprocess API's. The first
one is dumping functionality. For example, dpdk_proc_info can display
info from a currently-running or defunct process - list its
memzones/mempools/etc. - basically, everything there is to know about
the shared memory can be known that way. While this isn't a "real" use
case, it is useful for debugging.
More importantly, our multiprocess model provides resilience. In an
event of a crash, the entire application is not brought down - instead,
only the crashed process goes down. It's not /perfect/ resilience, of
course, and there are caveats (memory leaking, locks, etc.), but you do
get /some/ resilience that way - your process went down, you spin
another secondary and you're back up and running again.
The above described scenario is how most people (that i know of) appear
to be using multiprocess - some kind of "crash-resilient"
load-balancing/pipelining app.
>
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 15:13 4% ` Stephen Hemminger
@ 2019-04-08 15:13 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-08 15:13 UTC (permalink / raw)
To: David Marchand
Cc: Burakov, Anatoly, Ray Kinsella, Thomas Monjalon, techboard,
Bruce Richardson, dev, Kevin Traynor
On Mon, 8 Apr 2019 16:38:55 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
> wrote:
>
> > On 08-Apr-19 2:58 PM, David Marchand wrote:
> > > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> > >
> > > As a concrete proposal, my number one dream would be to see
> > > multiprocess
> > > gone. I also recall desire for "DPDK to be more lightweight", and i
> > > maintain that DPDK *cannot* be lightweight if we are to support
> > > multiprocess - we can have one or the other, but not both. However,
> > > realistically, i don't think dropping multiprocess is ever going to
> > > happen - not only it is too entrenched in DPDK use cases, it is
> > > actually
> > > quite useful despite its flaws.
> > >
> > >
> > > Well, honestly, I'd like to hear about this.
> > > What are the real usecases for multi process support?
> > > Do we have even a single opensource project that uses it?
> > >
> >
> > I'm aware of a few closed source usages of multiprocess. I also think
> > current versions of collectd rely on secondary process (there's been a
> > Telemetry API added to avoid that, but AFAIK the support for Telemetry
> > is not upstream in collectd yet), and so do/would any dump-style
> > applications - in fact, we ourselves include one such application in our
> > codebase (pdump, proc-info, etc.).
> >
>
> Sorry, I don't want to highjack this thread, I can start a separate thread
> if people feel like it.
> If we go with stabilisation, we must be careful that we want to support the
> features.
>
> So about multiprocess, again, in those closed source projects you know of,
> what are the usecases?
>
> For what we provide in dpdk pdump, proc-info, referring to oneself is not
> that convincing to me as I don't use those tools.
>
> I don't see what we could not achieve the same with a control thread
> running in the dpdk process and handling commands.
> It would be open to the outside via a more standard channel, like a UNIX
> socket or something like this.
> If we need to declare a dynamic channel, it can be constructed as an
> extension of the existing standard channel: we can open something like a
> POSIX shm and push things in it.
> Was this explored ?
>
>
Yes, there are several closed source applications using multi-process.
But the problem with that is no one tests with all the drivers, api's and
configurations in DPDK.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:38 4% ` David Marchand
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: David Marchand @ 2019-04-08 14:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 4:03 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 08-Apr-19 2:58 PM, David Marchand wrote:
> > On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> > <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
> >
> > As a concrete proposal, my number one dream would be to see
> > multiprocess
> > gone. I also recall desire for "DPDK to be more lightweight", and i
> > maintain that DPDK *cannot* be lightweight if we are to support
> > multiprocess - we can have one or the other, but not both. However,
> > realistically, i don't think dropping multiprocess is ever going to
> > happen - not only it is too entrenched in DPDK use cases, it is
> > actually
> > quite useful despite its flaws.
> >
> >
> > Well, honestly, I'd like to hear about this.
> > What are the real usecases for multi process support?
> > Do we have even a single opensource project that uses it?
> >
>
> I'm aware of a few closed source usages of multiprocess. I also think
> current versions of collectd rely on secondary process (there's been a
> Telemetry API added to avoid that, but AFAIK the support for Telemetry
> is not upstream in collectd yet), and so do/would any dump-style
> applications - in fact, we ourselves include one such application in our
> codebase (pdump, proc-info, etc.).
>
Sorry, I don't want to highjack this thread, I can start a separate thread
if people feel like it.
If we go with stabilisation, we must be careful that we want to support the
features.
So about multiprocess, again, in those closed source projects you know of,
what are the usecases?
For what we provide in dpdk pdump, proc-info, referring to oneself is not
that convincing to me as I don't use those tools.
I don't see what we could not achieve the same with a control thread
running in the dpdk process and handling commands.
It would be open to the outside via a more standard channel, like a UNIX
socket or something like this.
If we need to declare a dynamic channel, it can be constructed as an
extension of the existing standard channel: we can open something like a
POSIX shm and push things in it.
Was this explored ?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 14:02 4% ` Burakov, Anatoly
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 14:02 UTC (permalink / raw)
To: David Marchand
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On 08-Apr-19 2:58 PM, David Marchand wrote:
> On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly
> <anatoly.burakov@intel.com <mailto:anatoly.burakov@intel.com>> wrote:
>
> As a concrete proposal, my number one dream would be to see
> multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is
> actually
> quite useful despite its flaws.
>
>
> Well, honestly, I'd like to hear about this.
> What are the real usecases for multi process support?
> Do we have even a single opensource project that uses it?
>
I'm aware of a few closed source usages of multiprocess. I also think
current versions of collectd rely on secondary process (there's been a
Telemetry API added to avoid that, but AFAIK the support for Telemetry
is not upstream in collectd yet), and so do/would any dump-style
applications - in fact, we ourselves include one such application in our
codebase (pdump, proc-info, etc.).
>
> --
> David Marchand
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:58 4% ` David Marchand
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-04-08 13:58 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, techboard, Bruce Richardson, dev,
Kevin Traynor
On Mon, Apr 8, 2019 at 3:39 PM Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> As a concrete proposal, my number one dream would be to see multiprocess
> gone. I also recall desire for "DPDK to be more lightweight", and i
> maintain that DPDK *cannot* be lightweight if we are to support
> multiprocess - we can have one or the other, but not both. However,
> realistically, i don't think dropping multiprocess is ever going to
> happen - not only it is too entrenched in DPDK use cases, it is actually
> quite useful despite its flaws.
>
Well, honestly, I'd like to hear about this.
What are the real usecases for multi process support?
Do we have even a single opensource project that uses it?
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:38 4% ` Burakov, Anatoly
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-09 9:42 4% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 13:38 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 2:00 PM, Ray Kinsella wrote:
>
>
> On 08/04/2019 11:15, Burakov, Anatoly wrote:
>> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> [SNIP]
> [SNIP]
>>
>> My worry here is that some API's get more attention than others, but
>> requirements for freezing the API/ABI are applicable to all of them.
>>
>> Everyone loves discussing specifics of mbufs and dev API's, and I have
>> no doubt that DPDK community can arrive at a consensus with regards to
>> mbuf format etc. in a timely manner, since everyone has a vested
>> interest in those covering their use cases.
>> I have way less confidence
>> in us possibly having saner and more maintainable platform
>> initialization code,
>
> I think you are right, however its that same lack of enthusiasm that
> would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
> specification effort becoming an endless process, as it would always be
> low on DPDK contributors priority list.
>
> Instead I recommend we set an API freeze date to focus peoples minds,
> advertise what it means and contributors will respond and look after the
> areas they care/are responsible for.
>
>> simply because any attempt to change those will
>> likely be met with "please keep all of the old stuff working", which
>> gets us right back to where we started.
>>
>
> And to be honest that is a fair enough expectation from them, right?
> To Stephen's if we need to break it, let's do it once more and then
> never again.
>
Perhaps i didn't phrase myself well enough. When i say "DPDK 1.0
specification" i don't mean there literally should be a document with a
formal specification :)
Rather, i'm thinking more along the lines of, let's take a look at what
we have, and think of ways we can reduce the amount of code and improve
things without causing major inconveniences to great majority of users.
As in, if we want to "break once more and then never again", then maybe
instead of small incremental fixes here and there, we could actually do
a more drastic change that keeps perhaps 90% users happy instead of
100%, but which reduces maintenance/validation effort from 100% down to 30%.
As a concrete proposal, my number one dream would be to see multiprocess
gone. I also recall desire for "DPDK to be more lightweight", and i
maintain that DPDK *cannot* be lightweight if we are to support
multiprocess - we can have one or the other, but not both. However,
realistically, i don't think dropping multiprocess is ever going to
happen - not only it is too entrenched in DPDK use cases, it is actually
quite useful despite its flaws.
However, what *could* be realistic is to trim down complexity in EAL
init and system code in general - to me (again, a concrete proposal!),
that would be dropping igb_uio and supporting upstream kernel modules
only (VFIO, maybe uio_pci_generic if we're pushing it?), dropping 32-bit
support and legacy mem modes, and perhaps bumping kernel version and
removing some compatibility code as well. This would remove potentially
thousands of lines of code and keep EAL cleaner and more maintainable:
right now, we have two different hotplug mechanisms (UIO and VFIO), lots
of different memory/interrupt modes, etc., for no reason that is readily
apparent to me.
So, as you can see, an effort to review and delineate what we want to
support would be necessary if we want to ease the maintenance burden for
either myself or anyone that inherits this code, as well as reducing the
number of moving parts and, as a consequence, validation effort and
amount of bugs. We can't simply do it in a random release "just
because", but if we were to "break once more and then never again",
perhaps this is something that could be considered.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 13:00 4% ` Ray Kinsella
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 13:00 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08/04/2019 11:15, Burakov, Anatoly wrote:
> On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
>> On 07/04/2019 10:48, Thomas Monjalon wrote:
>>> 04/04/2019 16:07, Burakov, Anatoly:
>>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>> [SNIP]
[SNIP]
>
> My worry here is that some API's get more attention than others, but
> requirements for freezing the API/ABI are applicable to all of them.
>
> Everyone loves discussing specifics of mbufs and dev API's, and I have
> no doubt that DPDK community can arrive at a consensus with regards to
> mbuf format etc. in a timely manner, since everyone has a vested
> interest in those covering their use cases.
> I have way less confidence
> in us possibly having saner and more maintainable platform
> initialization code,
I think you are right, however its that same lack of enthusiasm that
would hamper a DPDK 1.0 specification. Similarly I can see a DPDK 1.0
specification effort becoming an endless process, as it would always be
low on DPDK contributors priority list.
Instead I recommend we set an API freeze date to focus peoples minds,
advertise what it means and contributors will respond and look after the
areas they care/are responsible for.
> simply because any attempt to change those will
> likely be met with "please keep all of the old stuff working", which
> gets us right back to where we started.
>
And to be honest that is a fair enough expectation from them, right?
To Stephen's if we need to break it, let's do it once more and then
never again.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 10:15 7% ` Burakov, Anatoly
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-08 10:15 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 08-Apr-19 10:04 AM, Ray Kinsella wrote:
> On 07/04/2019 10:48, Thomas Monjalon wrote:
>> 04/04/2019 16:07, Burakov, Anatoly:
>>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
>>> So, if we are to cement our core API - we have to make a concrete effort
>>> to specify what goes and what stays, if we want it to be maintainable.
>>> The DPDK 1.0 specification, if you will :)
>>
>> "DPDK 1.0 specification", that's a great project name :-)
>>
>
> Honestly - I would say that I am nervous of this.
>
> The definition of a DPDK 1.0 specification as a gate to API stability,
> feels like a "great plan tomorrow" instead of a "good plan" today. I
> think that getting people to dedicate time to such a specification might
> prove problematic and I could see this effort being very time consuming.
> It might never get completed.
>
> My preference would be to instead adopt a well-publicised community
> timeline for adopting more conservative API maintenance rules.
>
> Perhaps we could give ourselves as a community a time-limited window in
> which to address concerns around the API before they become hardened -
> perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
> to 9 months.
>
> We then would know the timeline when niggles like exposure of internal
> structures and mbuf structure needed to be sorted by and could
> prioritize accordingly.
>
> Ray K
>
My worry here is that some API's get more attention than others, but
requirements for freezing the API/ABI are applicable to all of them.
Everyone loves discussing specifics of mbufs and dev API's, and I have
no doubt that DPDK community can arrive at a consensus with regards to
mbuf format etc. in a timely manner, since everyone has a vested
interest in those covering their use cases. I have way less confidence
in us possibly having saner and more maintainable platform
initialization code, simply because any attempt to change those will
likely be met with "please keep all of the old stuff working", which
gets us right back to where we started.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-08 9:04 4% ` Ray Kinsella
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-14 0:42 9% ` Neil Horman
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-08 9:04 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: techboard, Bruce Richardson, dev, Kevin Traynor
On 07/04/2019 10:48, Thomas Monjalon wrote:
> 04/04/2019 16:07, Burakov, Anatoly:
>> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>> So, if we are to cement our core API - we have to make a concrete effort
>> to specify what goes and what stays, if we want it to be maintainable.
>> The DPDK 1.0 specification, if you will :)
>
> "DPDK 1.0 specification", that's a great project name :-)
>
Honestly - I would say that I am nervous of this.
The definition of a DPDK 1.0 specification as a gate to API stability,
feels like a "great plan tomorrow" instead of a "good plan" today. I
think that getting people to dedicate time to such a specification might
prove problematic and I could see this effort being very time consuming.
It might never get completed.
My preference would be to instead adopt a well-publicised community
timeline for adopting more conservative API maintenance rules.
Perhaps we could give ourselves as a community a time-limited window in
which to address concerns around the API before they become hardened -
perhaps say until DPDK 19.11 LTS, or something of the order of 6 months
to 9 months.
We then would know the timeline when niggles like exposure of internal
structures and mbuf structure needed to be sorted by and could
prioritize accordingly.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:48 4% ` Thomas Monjalon
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
@ 2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:48 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: techboard, Ray Kinsella, Bruce Richardson, dev, Kevin Traynor
04/04/2019 16:07, Burakov, Anatoly:
> On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
> > On 04/04/2019 11:54, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >> Actually, I think we *do* need to constrain the pace of development for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project - it
> >> should just start acting like it.
> >
> > I 100% agree.
> >
> > If you break your users stuff regularly enough, they will eventually
> > start looking around for an alternative that doesn't break their stuff
> > quiet so regularly.
> >
> > We often use the pace of innovation in DPDK as justification for ABI/API
> > breakages, but that approach is a real rarity among the Open Source
> > community. I can't think of any mature project off-hand that share's it.
> >
> > I would ask is Linux any less innovative because they offer a stable API
> > and have an absolute commitment to never breaking userspace? Would Linux
> > have ever been as popular as it is today it they broke userspace every
> > quarter?
> >
> > They reality is that they (Linux) find workarounds and compromise
> > because there is an uber-maintainer Linus who had a strong ethos from
> > the start not to break their users stuff - we need the same ethos in DPDK.
> >
> >>
> >> Now, in terms of features like the memory rework, that is indeed a case
> >> that there was no alternative other than a massive ABI break. However, for
> >> that rework there was a strong need for improvement in that area that we
> >> can make the case for an ABI break to support it - and it is of a scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are of
> >> that scale.
> >
> > I would also be inclined to agree with Bruce's points on memory rework
> > was somewhat of an outlier, we don't see many like it.
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should reduce
> >> the scope for ABI breaks.
> >> 2. Once done, I think we should commit to having an ABI break only in the
> >> rarest of circumstances, and only with very large justification. I want us
> >> to get to the point where DPDK releases can immediately be picked up by all
> >> linux distros and rolled out because they are ABI compatible.
> >
> > The work that Anatoly describes removing APIs that exposed internal
> > structures and Stephen H's RFC similarly are good examples of the kind
> > of work required to prepare for this change. We need to take a good look
> > at the API and reduce the number of unnecessary internal structures
> > exposed.
> >
> > I never expected it going to to be a big bang - but is a definite
> > direction we need to move towards over the next few release.
>
> ...in this case, we have to think long and hard about the fabled EAL
> rework/split, and in general *specifying* what is it that we want to
> support, and the use cases that we want to target. Right now there is a
> huge mountain of technical debt and kludges and workarounds that has
> accumulated over the years, and it exists precisely because "every
> change breaks someone's workflow".
>
> For example, just in memory subsystem alone, we have legacy mem, because
> some use cases require huge amounts of contiguous memory, and not
> everyone is using VFIO; there's all of the 32-bit related workarounds
> and hacks; there's the single-file-segments stuff that could have been
> the default if not for the fact that we support kernels that don't
> support fallocate(); there are two different ways of doing in-memory
> mode, because not all kernels support memfd's; there is a gargantuan
> pile of workarounds (and "known issues", and just code in general) all
> over the DPDK codebase just to support our multiprocess model and all of
> the various warts that come with it.
>
> In fact, i would even go as far as to say that *most* of EAL ABI breaks
> have been due to the fact that we store data in shared memory because of
> multiprocess - so there is simply no way we can change these internal
> data structures without ABI breaks, because even if they're not exposed
> through user-facing API, they are still exposed by virtue of secondary
> processes basically having an ABI contract with primary process instances.
>
> So, if we are to cement our core API - we have to make a concrete effort
> to specify what goes and what stays, if we want it to be maintainable.
> The DPDK 1.0 specification, if you will :)
"DPDK 1.0 specification", that's a great project name :-)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-07 9:37 4% ` Thomas Monjalon
@ 2019-04-07 9:37 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-07 9:37 UTC (permalink / raw)
To: techboard
Cc: Ray Kinsella, Bruce Richardson, Luca Boccassi, Burakov, Anatoly,
dev, Kevin Traynor
05/04/2019 15:25, Ray Kinsella:
> On 04/04/2019 14:10, Bruce Richardson wrote:
> > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
> >> On 04/04/2019 13:02, Luca Boccassi wrote:
> >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> >>
> > I would be too, with certain exceptions - rte_mbuf for one. Any structures
> > that are used by applications cannot be made opaque, as apps do not want to
> > pay the cost of having to call a function every time they want to access
> > something from one of those structures.
>
> These the layout of these structures really must become sacrosanct.
> As Stephen points out, there may be room for a one more change - fool me
> once - to future poof the structure but after, that these structure will
> become very hard to change.
Yes, looks like a good plan.
> > Thankfully for us, we have plenty of other structures that we can work on
> > in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> > we work through those first, allowing us to hone our ABI-break avoidance
> > skills.
+1 to work on obvious cases first.
I think we should not wait too much to improve mbuf
with some dynamically registered fields, because it may be
long to achieve such an important feature and make everybody happy.
Note: we may have to sacrifice a few cycles for some features
like distributor or IPsec.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
@ 2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
@ 2019-04-05 20:30 3% Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-05 20:30 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The symbols in the EXPERIMENTAL were close to alphabetic
order but running sort showed several mistakes.
This has no impact on code, API, ABI or otherwise.
Purely for humans.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/rte_eal_version.map | 36 +++++++++++++++---------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..33f2c303a361 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -277,6 +277,14 @@ EXPERIMENTAL {
rte_class_unregister;
rte_ctrl_thread_create;
rte_delay_us_sleep;
+ rte_devargs_add;
+ rte_devargs_dump;
+ rte_devargs_insert;
+ rte_devargs_next;
+ rte_devargs_parse;
+ rte_devargs_parsef;
+ rte_devargs_remove;
+ rte_devargs_type_count;
rte_dev_dma_map;
rte_dev_dma_unmap;
rte_dev_event_callback_process;
@@ -289,14 +297,6 @@ EXPERIMENTAL {
rte_dev_is_probed;
rte_dev_iterator_init;
rte_dev_iterator_next;
- rte_devargs_add;
- rte_devargs_dump;
- rte_devargs_insert;
- rte_devargs_next;
- rte_devargs_parse;
- rte_devargs_parsef;
- rte_devargs_remove;
- rte_devargs_type_count;
rte_eal_cleanup;
rte_extmem_attach;
rte_extmem_detach;
@@ -306,19 +306,19 @@ EXPERIMENTAL {
rte_fbarray_destroy;
rte_fbarray_detach;
rte_fbarray_dump_metadata;
- rte_fbarray_find_idx;
rte_fbarray_find_biggest_free;
rte_fbarray_find_biggest_used;
+ rte_fbarray_find_contig_free;
+ rte_fbarray_find_contig_used;
+ rte_fbarray_find_idx;
rte_fbarray_find_next_free;
- rte_fbarray_find_next_used;
rte_fbarray_find_next_n_free;
rte_fbarray_find_next_n_used;
+ rte_fbarray_find_next_used;
rte_fbarray_find_prev_free;
- rte_fbarray_find_prev_used;
rte_fbarray_find_prev_n_free;
rte_fbarray_find_prev_n_used;
- rte_fbarray_find_contig_free;
- rte_fbarray_find_contig_used;
+ rte_fbarray_find_prev_used;
rte_fbarray_find_rev_biggest_free;
rte_fbarray_find_rev_biggest_used;
rte_fbarray_find_rev_contig_free;
@@ -346,24 +346,24 @@ EXPERIMENTAL {
rte_mem_event_callback_register;
rte_mem_event_callback_unregister;
rte_mem_iova2virt;
- rte_mem_set_dma_mask;
- rte_mem_virt2memseg;
- rte_mem_virt2memseg_list;
rte_memseg_contig_walk;
rte_memseg_contig_walk_thread_unsafe;
rte_memseg_get_fd;
rte_memseg_get_fd_offset;
- rte_memseg_get_fd_thread_unsafe;
rte_memseg_get_fd_offset_thread_unsafe;
+ rte_memseg_get_fd_thread_unsafe;
rte_memseg_list_walk;
rte_memseg_list_walk_thread_unsafe;
rte_memseg_walk;
rte_memseg_walk_thread_unsafe;
+ rte_mem_set_dma_mask;
+ rte_mem_virt2memseg;
+ rte_mem_virt2memseg_list;
rte_mp_action_register;
rte_mp_action_unregister;
rte_mp_reply;
- rte_mp_request_sync;
rte_mp_request_async;
+ rte_mp_request_sync;
rte_mp_sendmsg;
rte_option_register;
rte_realloc_socket;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
@ 2019-04-05 14:35 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] power: fix non thread-safe power env modification
@ 2019-04-05 14:35 4% ` Hajkowski
2019-04-05 14:35 4% ` Hajkowski
0 siblings, 1 reply; 200+ results
From: Hajkowski @ 2019-04-05 14:35 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable, Anatoly Burakov
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:30 4% ` Ray Kinsella
@ 2019-04-05 13:30 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:30 UTC (permalink / raw)
To: Kevin Traynor, Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 21:13, Kevin Traynor wrote:
> On 04/04/2019 20:08, Wiles, Keith wrote:
>>
>>
>>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>>
>>> On 04/04/2019 11:54, Bruce Richardson wrote:
>>> <snip>
>>>
>>>>
>>>> My thoughts on the matter are:
>>>> 1. I think we really need to do work to start hiding more of our data
>>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>>> the scope for ABI breaks.
>>>> 2. Once done, I think we should commit to having an ABI break only in the
>>>> rarest of circumstances, and only with very large justification. I want us
>>>> to get to the point where DPDK releases can immediately be picked up by all
>>>> linux distros and rolled out because they are ABI compatible.
>>>>
>>>
>>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>>> APIs at transition from experimental to core). Just as a way to get more
>>> eyeballs and scrutiny on them.
>>
>> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>>
>
> We'll only find out if they are bad when they need ABI breaks later :-)
>
> My point is a good way to avoid future ABI breaks is to have more
> reviews on the APIs in the first place. Techboard approval might be one
> way, or 3 acks or something else.
+1 on this ... an API break should invite a higher level of scrutiny.
>
>>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>>> me as a plan where we end up with the same number of ABI breaks as before,
>>>> just balled into one release.
>>>>
>>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>>> case that each distro will only ship one version of DPDK, or is it possible
>>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>>
>>>
>>> It would probably double validation and maintenance, so it would require
>>> a lot of extra effort.
>>>
>>>>
>>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>>> similar.
>>>>
>>>> Regards,
>>>> /Bruce
>>>>
>>>
>>
>> Regards,
>> Keith
>>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:29 4% ` Ray Kinsella
@ 2019-04-05 13:29 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-05 13:29 UTC (permalink / raw)
To: Wiles, Keith, Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
New APIs will be experimental in any case, as you say they are less of
problem.
I agree, if we can make a change and preserve API compatibility with
versioning then everyone is happy.
Changes only need be referred to the higher power in case on absolutely
breakage - _but_ these need to become as rare as hens teeth.
>>
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-05 13:25 4% ` Ray Kinsella
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-05 13:25 UTC (permalink / raw)
To: Bruce Richardson
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On 04/04/2019 14:10, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>>
>>
>> On 04/04/2019 13:02, Luca Boccassi wrote:
>>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>
> I would be too, with certain exceptions - rte_mbuf for one. Any structures
> that are used by applications cannot be made opaque, as apps do not want to
> pay the cost of having to call a function every time they want to access
> something from one of those structures.
These the layout of these structures really must become sacrosanct.
As Stephen points out, there may be room for a one more change - fool me
once - to future poof the structure but after, that these structure will
become very hard to change.
>
> Thankfully for us, we have plenty of other structures that we can work on
> in the meantime that can be made private to avoid ABI breaks! :-) I suggest
> we work through those first, allowing us to hone our ABI-break avoidance
> skills.
>
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:40 0% ` Ferruh Yigit
@ 2019-04-05 11:40 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:40 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 12:31 PM, Ferruh Yigit wrote:
> On 4/5/2019 10:05 AM, Qi Zhang wrote:
>> ---
>> v5:
>> 1. add ABI break notification in commit log of PATCH 1/5
>> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
>> comments)
>>
>> V4:
>> 1. rebased to the latest code.
>> 2. deleted misleading statement.
>>
>> V3:
>> 1. fixed issue in release note.
>> 2. fixed check patch issue.
>> 3. spilted eal related change to a new patch.
>>
>> V2:
>> 1. move testpmd related changes to a new patch.
>> 2. added release note update.
>>
>>
>> Qiming Yang (5):
>> ethdev: add VXLAN-GPE macro
>> net/i40e: add support for VXLAN-GPE
>> net/i40e: support VXLAN-GPE classification
>> app/testpmd: add VXLAN-GPE to tunnel type
>> doc: add release note for VXLAN-GPE support
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
@ 2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:40 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 12:31 PM, Ferruh Yigit wrote:
> On 4/5/2019 10:05 AM, Qi Zhang wrote:
>> ---
>> v5:
>> 1. add ABI break notification in commit log of PATCH 1/5
>> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
>> comments)
>>
>> V4:
>> 1. rebased to the latest code.
>> 2. deleted misleading statement.
>>
>> V3:
>> 1. fixed issue in release note.
>> 2. fixed check patch issue.
>> 3. spilted eal related change to a new patch.
>>
>> V2:
>> 1. move testpmd related changes to a new patch.
>> 2. added release note update.
>>
>>
>> Qiming Yang (5):
>> ethdev: add VXLAN-GPE macro
>> net/i40e: add support for VXLAN-GPE
>> net/i40e: support VXLAN-GPE classification
>> app/testpmd: add VXLAN-GPE to tunnel type
>> doc: add release note for VXLAN-GPE support
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
@ 2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:31 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 10:05 AM, Qi Zhang wrote:
> ---
> v5:
> 1. add ABI break notification in commit log of PATCH 1/5
> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
> comments)
>
> V4:
> 1. rebased to the latest code.
> 2. deleted misleading statement.
>
> V3:
> 1. fixed issue in release note.
> 2. fixed check patch issue.
> 3. spilted eal related change to a new patch.
>
> V2:
> 1. move testpmd related changes to a new patch.
> 2. added release note update.
>
>
> Qiming Yang (5):
> ethdev: add VXLAN-GPE macro
> net/i40e: add support for VXLAN-GPE
> net/i40e: support VXLAN-GPE classification
> app/testpmd: add VXLAN-GPE to tunnel type
> doc: add release note for VXLAN-GPE support
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
@ 2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:31 UTC (permalink / raw)
To: Qi Zhang, bernard.iremonger; +Cc: dev
On 4/5/2019 10:05 AM, Qi Zhang wrote:
> ---
> v5:
> 1. add ABI break notification in commit log of PATCH 1/5
> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
> comments)
>
> V4:
> 1. rebased to the latest code.
> 2. deleted misleading statement.
>
> V3:
> 1. fixed issue in release note.
> 2. fixed check patch issue.
> 3. spilted eal related change to a new patch.
>
> V2:
> 1. move testpmd related changes to a new patch.
> 2. added release note update.
>
>
> Qiming Yang (5):
> ethdev: add VXLAN-GPE macro
> net/i40e: add support for VXLAN-GPE
> net/i40e: support VXLAN-GPE classification
> app/testpmd: add VXLAN-GPE to tunnel type
> doc: add release note for VXLAN-GPE support
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 11:22 0% ` Neil Horman
@ 2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-05 11:22 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> Currently, when symbols get promoted from the EXPERIMENTAL section to a
> stable ABI section, the script complains they should go to the
> EXPERIMENTAL section.
>
> Example:
> ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> expected to be added in the EXPERIMENTAL section of the version map
>
> This is legit.
> Moving from a stable ABI to another is also allowed, but must have gone
> through the proper process.
>
> Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 020da7e..40eb953 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -105,27 +105,37 @@ check_for_rule_violations()
> continue
> fi
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + oldsecname=$(sed -n \
> + "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
> +
> + # A symbol can not enter a non experimental
> + # section directly
> + if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
> then
> - # Symbols that are getting added in a section
> - # other than the experimental section
> - # to be moving from an already supported
> - # section or its a violation
> - grep -q \
> - "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
> - if [ $? -ne 0 ]
> - then
> - echo -n "ERROR: symbol $symname "
> - echo -n "is added in the $secname "
> - echo -n "section, but is expected to "
> - echo -n "be added in the EXPERIMENTAL "
> - echo "section of the version map"
> - ret=1
> - fi
> + echo -n "ERROR: symbol $symname "
> + echo -n "is added in the $secname "
> + echo -n "section, but is expected to "
> + echo -n "be added in the EXPERIMENTAL "
> + echo "section of the version map"
> + ret=1
> + continue
> + fi
> +
> + # This symbol is moving between two sections (the
> + # original section is not experimental).
> + # This can be legit, just warn.
> + if [ "$oldsecname" != 'EXPERIMENTAL' ]
> + then
> + echo -n "INFO: symbol $symname is being "
> + echo -n "moved from $oldsecname to $secname. "
> + echo -n "Ensure that it has gone through the "
> + echo "deprecation process"
> + continue
> fi
> else
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + if ! grep -q "$mname $symname .* add" "$mapdb" && \
> + [ "$secname" != "EXPERIMENTAL" ]
> then
> # Just inform users that non-experimenal
> # symbols need to go through a deprecation
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
2019-04-05 8:17 4% ` David Marchand
@ 2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Neil Horman @ 2019-04-05 11:22 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> Currently, when symbols get promoted from the EXPERIMENTAL section to a
> stable ABI section, the script complains they should go to the
> EXPERIMENTAL section.
>
> Example:
> ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> expected to be added in the EXPERIMENTAL section of the version map
>
> This is legit.
> Moving from a stable ABI to another is also allowed, but must have gone
> through the proper process.
>
> Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 020da7e..40eb953 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -105,27 +105,37 @@ check_for_rule_violations()
> continue
> fi
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + oldsecname=$(sed -n \
> + "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
> +
> + # A symbol can not enter a non experimental
> + # section directly
> + if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
> then
> - # Symbols that are getting added in a section
> - # other than the experimental section
> - # to be moving from an already supported
> - # section or its a violation
> - grep -q \
> - "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
> - if [ $? -ne 0 ]
> - then
> - echo -n "ERROR: symbol $symname "
> - echo -n "is added in the $secname "
> - echo -n "section, but is expected to "
> - echo -n "be added in the EXPERIMENTAL "
> - echo "section of the version map"
> - ret=1
> - fi
> + echo -n "ERROR: symbol $symname "
> + echo -n "is added in the $secname "
> + echo -n "section, but is expected to "
> + echo -n "be added in the EXPERIMENTAL "
> + echo "section of the version map"
> + ret=1
> + continue
> + fi
> +
> + # This symbol is moving between two sections (the
> + # original section is not experimental).
> + # This can be legit, just warn.
> + if [ "$oldsecname" != 'EXPERIMENTAL' ]
> + then
> + echo -n "INFO: symbol $symname is being "
> + echo -n "moved from $oldsecname to $secname. "
> + echo -n "Ensure that it has gone through the "
> + echo "deprecation process"
> + continue
> fi
> else
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + if ! grep -q "$mname $symname .* add" "$mapdb" && \
> + [ "$secname" != "EXPERIMENTAL" ]
> then
> # Just inform users that non-experimenal
> # symbols need to go through a deprecation
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 11:12 3% ` Ferruh Yigit
@ 2019-04-05 11:12 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:12 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
On 4/5/2019 11:37 AM, Thomas Monjalon wrote:
> Hi,
>
> Sorry for not catching it before, but I was not Cc.
> Please use git send-email --to-cmd devtools/get-maintainer.sh
>
> 05/04/2019 11:42, Ferruh Yigit:
>> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>>>> From: Qiming Yang <qiming.yang@intel.com>
>>>>
>>>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>>>> problem when running with new version of the ethdev shared
>>>> library.
>>>>
>>>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>>>> ---
> [...]
>>>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>>>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>>>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>>>> RTE_TUNNEL_TYPE_NVGRE,
>>>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>> RTE_L2_TUNNEL_TYPE_E_TAG,
>>>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>
>>> Not sure, why do you consider it as an ABI breakage?
>>
>> I think it is API breakage instead of ABI.
>>
>> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
>> If the application is using the MAX enum item, with the new version of the
>> ethdev the MAX value will be different and this can break the app.
>>
>> Like:
>>
>> app_function(..) {
>> ret = lib_foo()
>> if (ret == RTE_TUNNEL_TYPE_MAX)
>> ret -1;
>> }
>>
>> lib_foo(..) {
>> return RTE_TUNNEL_TYPE_MAX;
>> }
>>
>>
>> When app compiled, MAX was '7' and app is comparing ret value against '7', but
>> with new version of DPDK, 'lib_foo()' will return '8' instead.
>
> I would vote for ABI because it is a value change.
>
> Anyway, it must be noticed in the release notes.
>
> As we are already breaking ethdev ABI in this release,
> and it is a very basic change, I agree to accept it in 19.05.
+1
>
> In future, we should make sure that such addition is possible
> without any breakage.
+1. Otherwise there is no escape from it and adding a new tunnel type shouldn't
cause and ABI/API breakage.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
@ 2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-05 11:12 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
On 4/5/2019 11:37 AM, Thomas Monjalon wrote:
> Hi,
>
> Sorry for not catching it before, but I was not Cc.
> Please use git send-email --to-cmd devtools/get-maintainer.sh
>
> 05/04/2019 11:42, Ferruh Yigit:
>> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>>>> From: Qiming Yang <qiming.yang@intel.com>
>>>>
>>>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>>>> problem when running with new version of the ethdev shared
>>>> library.
>>>>
>>>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>>>> ---
> [...]
>>>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>>>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>>>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>>>> RTE_TUNNEL_TYPE_NVGRE,
>>>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>>>> RTE_L2_TUNNEL_TYPE_E_TAG,
>>>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>
>>> Not sure, why do you consider it as an ABI breakage?
>>
>> I think it is API breakage instead of ABI.
>>
>> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
>> If the application is using the MAX enum item, with the new version of the
>> ethdev the MAX value will be different and this can break the app.
>>
>> Like:
>>
>> app_function(..) {
>> ret = lib_foo()
>> if (ret == RTE_TUNNEL_TYPE_MAX)
>> ret -1;
>> }
>>
>> lib_foo(..) {
>> return RTE_TUNNEL_TYPE_MAX;
>> }
>>
>>
>> When app compiled, MAX was '7' and app is comparing ret value against '7', but
>> with new version of DPDK, 'lib_foo()' will return '8' instead.
>
> I would vote for ABI because it is a value change.
>
> Anyway, it must be noticed in the release notes.
>
> As we are already breaking ethdev ABI in this release,
> and it is a very basic change, I agree to accept it in 19.05.
+1
>
> In future, we should make sure that such addition is possible
> without any breakage.
+1. Otherwise there is no escape from it and adding a new tunnel type shouldn't
cause and ABI/API breakage.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 10:37 4% ` Thomas Monjalon
@ 2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 10:37 UTC (permalink / raw)
To: Ferruh Yigit, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
Hi,
Sorry for not catching it before, but I was not Cc.
Please use git send-email --to-cmd devtools/get-maintainer.sh
05/04/2019 11:42, Ferruh Yigit:
> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> >> From: Qiming Yang <qiming.yang@intel.com>
> >>
> >> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> >> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> >> problem when running with new version of the ethdev shared
> >> library.
> >>
> >> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> >> ---
[...]
> >> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> >> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> >> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> >> RTE_TUNNEL_TYPE_NVGRE,
> >> RTE_TUNNEL_TYPE_IP_IN_GRE,
> >> RTE_L2_TUNNEL_TYPE_E_TAG,
> >> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> >
> > Not sure, why do you consider it as an ABI breakage?
>
> I think it is API breakage instead of ABI.
>
> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
> If the application is using the MAX enum item, with the new version of the
> ethdev the MAX value will be different and this can break the app.
>
> Like:
>
> app_function(..) {
> ret = lib_foo()
> if (ret == RTE_TUNNEL_TYPE_MAX)
> ret -1;
> }
>
> lib_foo(..) {
> return RTE_TUNNEL_TYPE_MAX;
> }
>
>
> When app compiled, MAX was '7' and app is comparing ret value against '7', but
> with new version of DPDK, 'lib_foo()' will return '8' instead.
I would vote for ABI because it is a value change.
Anyway, it must be noticed in the release notes.
As we are already breaking ethdev ABI in this release,
and it is a very basic change, I agree to accept it in 19.05.
In future, we should make sure that such addition is possible
without any breakage.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
@ 2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 10:37 UTC (permalink / raw)
To: Ferruh Yigit, Ananyev, Konstantin, Yang, Qiming
Cc: dev, Zhang, Qi Z, Iremonger, Bernard, bruce.richardson
Hi,
Sorry for not catching it before, but I was not Cc.
Please use git send-email --to-cmd devtools/get-maintainer.sh
05/04/2019 11:42, Ferruh Yigit:
> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> >> From: Qiming Yang <qiming.yang@intel.com>
> >>
> >> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> >> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> >> problem when running with new version of the ethdev shared
> >> library.
> >>
> >> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> >> ---
[...]
> >> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> >> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> >> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> >> RTE_TUNNEL_TYPE_NVGRE,
> >> RTE_TUNNEL_TYPE_IP_IN_GRE,
> >> RTE_L2_TUNNEL_TYPE_E_TAG,
> >> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> >
> > Not sure, why do you consider it as an ABI breakage?
>
> I think it is API breakage instead of ABI.
>
> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
> If the application is using the MAX enum item, with the new version of the
> ethdev the MAX value will be different and this can break the app.
>
> Like:
>
> app_function(..) {
> ret = lib_foo()
> if (ret == RTE_TUNNEL_TYPE_MAX)
> ret -1;
> }
>
> lib_foo(..) {
> return RTE_TUNNEL_TYPE_MAX;
> }
>
>
> When app compiled, MAX was '7' and app is comparing ret value against '7', but
> with new version of DPDK, 'lib_foo()' will return '8' instead.
I would vote for ABI because it is a value change.
Anyway, it must be noticed in the release notes.
As we are already breaking ethdev ABI in this release,
and it is a very basic change, I agree to accept it in 19.05.
In future, we should make sure that such addition is possible
without any breakage.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:42 3% ` Ferruh Yigit
@ 2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 9:42 UTC (permalink / raw)
To: Ananyev, Konstantin, Zhang, Qi Z, Iremonger, Bernard; +Cc: dev, Yang, Qiming
On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Friday, April 5, 2019 10:06 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
>> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
>> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>>
>> From: Qiming Yang <qiming.yang@intel.com>
>>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>> problem when running with new version of the ethdev shared
>> library.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae24c..b3416341b 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>
> Not sure, why do you consider it as an ABI breakage?
I think it is API breakage instead of ABI.
This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
If the application is using the MAX enum item, with the new version of the
ethdev the MAX value will be different and this can break the app.
Like:
app_function(..) {
ret = lib_foo()
if (ret == RTE_TUNNEL_TYPE_MAX)
ret -1;
}
lib_foo(..) {
return RTE_TUNNEL_TYPE_MAX;
}
When app compiled, MAX was '7' and app is comparing ret value against '7', but
with new version of DPDK, 'lib_foo()' will return '8' instead.
> Konstantin
>
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>> --
>> 2.13.6
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
@ 2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-05 9:42 UTC (permalink / raw)
To: Ananyev, Konstantin, Zhang, Qi Z, Iremonger, Bernard; +Cc: dev, Yang, Qiming
On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Friday, April 5, 2019 10:06 AM
>> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
>> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
>> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>>
>> From: Qiming Yang <qiming.yang@intel.com>
>>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>> problem when running with new version of the ethdev shared
>> library.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae24c..b3416341b 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>
> Not sure, why do you consider it as an ABI breakage?
I think it is API breakage instead of ABI.
This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
If the application is using the MAX enum item, with the new version of the
ethdev the MAX value will be different and this can break the app.
Like:
app_function(..) {
ret = lib_foo()
if (ret == RTE_TUNNEL_TYPE_MAX)
ret -1;
}
lib_foo(..) {
return RTE_TUNNEL_TYPE_MAX;
}
When app compiled, MAX was '7' and app is comparing ret value against '7', but
with new version of DPDK, 'lib_foo()' will return '8' instead.
> Konstantin
>
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>> --
>> 2.13.6
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:36 3% ` Ananyev, Konstantin
@ 2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-05 9:36 UTC (permalink / raw)
To: Zhang, Qi Z, Yigit, Ferruh, Zhang, Qi Z, Iremonger, Bernard
Cc: dev, Yang, Qiming
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> Sent: Friday, April 5, 2019 10:06 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>
> From: Qiming Yang <qiming.yang@intel.com>
>
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> problem when running with new version of the ethdev shared
> library.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae24c..b3416341b 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
Not sure, why do you consider it as an ABI breakage?
Konstantin
> RTE_TUNNEL_TYPE_MAX,
> };
>
> --
> 2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
@ 2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ananyev, Konstantin @ 2019-04-05 9:36 UTC (permalink / raw)
To: Zhang, Qi Z, Yigit, Ferruh, Zhang, Qi Z, Iremonger, Bernard
Cc: dev, Yang, Qiming
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qi Zhang
> Sent: Friday, April 5, 2019 10:06 AM
> To: Yigit, Ferruh <ferruh.yigit@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>
> From: Qiming Yang <qiming.yang@intel.com>
>
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> problem when running with new version of the ethdev shared
> library.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae24c..b3416341b 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
Not sure, why do you consider it as an ABI breakage?
Konstantin
> RTE_TUNNEL_TYPE_MAX,
> };
>
> --
> 2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev, Qiming Yang
From: Qiming Yang <qiming.yang@intel.com>
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae24c..b3416341b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
RTE_TUNNEL_TYPE_MAX,
};
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev
---
v5:
1. add ABI break notification in commit log of PATCH 1/5
2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
comments)
V4:
1. rebased to the latest code.
2. deleted misleading statement.
V3:
1. fixed issue in release note.
2. fixed check patch issue.
3. spilted eal related change to a new patch.
V2:
1. move testpmd related changes to a new patch.
2. added release note update.
Qiming Yang (5):
ethdev: add VXLAN-GPE macro
net/i40e: add support for VXLAN-GPE
net/i40e: support VXLAN-GPE classification
app/testpmd: add VXLAN-GPE to tunnel type
doc: add release note for VXLAN-GPE support
app/test-pmd/cmdline.c | 19 ++++++++++++-------
doc/guides/rel_notes/release_19_05.rst | 7 +++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++++++----
drivers/net/i40e/i40e_ethdev.c | 16 ++++++++++++----
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
5 files changed, 39 insertions(+), 15 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
@ 2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2 siblings, 2 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev, Qiming Yang
From: Qiming Yang <qiming.yang@intel.com>
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang <qiming.yang@intel.com>
---
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae24c..b3416341b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
RTE_TUNNEL_TYPE_MAX,
};
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
@ 2019-04-05 9:05 3% Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Qi Zhang @ 2019-04-05 9:05 UTC (permalink / raw)
To: ferruh.yigit, qi.z.zhang, bernard.iremonger; +Cc: dev
---
v5:
1. add ABI break notification in commit log of PATCH 1/5
2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's
comments)
V4:
1. rebased to the latest code.
2. deleted misleading statement.
V3:
1. fixed issue in release note.
2. fixed check patch issue.
3. spilted eal related change to a new patch.
V2:
1. move testpmd related changes to a new patch.
2. added release note update.
Qiming Yang (5):
ethdev: add VXLAN-GPE macro
net/i40e: add support for VXLAN-GPE
net/i40e: support VXLAN-GPE classification
app/testpmd: add VXLAN-GPE to tunnel type
doc: add release note for VXLAN-GPE support
app/test-pmd/cmdline.c | 19 ++++++++++++-------
doc/guides/rel_notes/release_19_05.rst | 7 +++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++++++----
drivers/net/i40e/i40e_ethdev.c | 16 ++++++++++++----
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
5 files changed, 39 insertions(+), 15 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
2019-04-05 8:30 4% ` Thomas Monjalon
@ 2019-04-05 8:30 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-05 8:30 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable, Olivier Matz
19/03/2019 18:19, Neil Horman:
> On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> > The doc examples are not aligned on the script following the
> > incriminated commit.
> >
> > Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> > Cc: stable@dpdk.org
> >
> > Cc: Olivier Matz <olivier.matz@6wind.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
@ 2019-04-05 8:30 4% ` Thomas Monjalon
2019-04-05 8:30 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-05 8:30 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Neil Horman, stable, Olivier Matz
19/03/2019 18:19, Neil Horman:
> On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> > The doc examples are not aligned on the script following the
> > incriminated commit.
> >
> > Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> > Cc: stable@dpdk.org
> >
> > Cc: Olivier Matz <olivier.matz@6wind.com>
> > Cc: Neil Horman <nhorman@tuxdriver.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
@ 2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-04-05 8:17 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Currently, when symbols get promoted from the EXPERIMENTAL section to a
stable ABI section, the script complains they should go to the
EXPERIMENTAL section.
Example:
ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
expected to be added in the EXPERIMENTAL section of the version map
This is legit.
Moving from a stable ABI to another is also allowed, but must have gone
through the proper process.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 020da7e..40eb953 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -105,27 +105,37 @@ check_for_rule_violations()
continue
fi
- if [ "$secname" != "EXPERIMENTAL" ]
+ oldsecname=$(sed -n \
+ "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
+
+ # A symbol can not enter a non experimental
+ # section directly
+ if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
then
- # Symbols that are getting added in a section
- # other than the experimental section
- # to be moving from an already supported
- # section or its a violation
- grep -q \
- "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
- if [ $? -ne 0 ]
- then
- echo -n "ERROR: symbol $symname "
- echo -n "is added in the $secname "
- echo -n "section, but is expected to "
- echo -n "be added in the EXPERIMENTAL "
- echo "section of the version map"
- ret=1
- fi
+ echo -n "ERROR: symbol $symname "
+ echo -n "is added in the $secname "
+ echo -n "section, but is expected to "
+ echo -n "be added in the EXPERIMENTAL "
+ echo "section of the version map"
+ ret=1
+ continue
+ fi
+
+ # This symbol is moving between two sections (the
+ # original section is not experimental).
+ # This can be legit, just warn.
+ if [ "$oldsecname" != 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname is being "
+ echo -n "moved from $oldsecname to $secname. "
+ echo -n "Ensure that it has gone through the "
+ echo "deprecation process"
+ continue
fi
else
- if [ "$secname" != "EXPERIMENTAL" ]
+ if ! grep -q "$mname $symname .* add" "$mapdb" && \
+ [ "$secname" != "EXPERIMENTAL" ]
then
# Just inform users that non-experimenal
# symbols need to go through a deprecation
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
@ 2019-04-05 8:17 4% David Marchand
2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-04-05 8:17 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Currently, when symbols get promoted from the EXPERIMENTAL section to a
stable ABI section, the script complains they should go to the
EXPERIMENTAL section.
Example:
ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
expected to be added in the EXPERIMENTAL section of the version map
This is legit.
Moving from a stable ABI to another is also allowed, but must have gone
through the proper process.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 44 +++++++++++++++++++++++++----------------
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 020da7e..40eb953 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -105,27 +105,37 @@ check_for_rule_violations()
continue
fi
- if [ "$secname" != "EXPERIMENTAL" ]
+ oldsecname=$(sed -n \
+ "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
+
+ # A symbol can not enter a non experimental
+ # section directly
+ if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
then
- # Symbols that are getting added in a section
- # other than the experimental section
- # to be moving from an already supported
- # section or its a violation
- grep -q \
- "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
- if [ $? -ne 0 ]
- then
- echo -n "ERROR: symbol $symname "
- echo -n "is added in the $secname "
- echo -n "section, but is expected to "
- echo -n "be added in the EXPERIMENTAL "
- echo "section of the version map"
- ret=1
- fi
+ echo -n "ERROR: symbol $symname "
+ echo -n "is added in the $secname "
+ echo -n "section, but is expected to "
+ echo -n "be added in the EXPERIMENTAL "
+ echo "section of the version map"
+ ret=1
+ continue
+ fi
+
+ # This symbol is moving between two sections (the
+ # original section is not experimental).
+ # This can be legit, just warn.
+ if [ "$oldsecname" != 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname is being "
+ echo -n "moved from $oldsecname to $secname. "
+ echo -n "Ensure that it has gone through the "
+ echo "deprecation process"
+ continue
fi
else
- if [ "$secname" != "EXPERIMENTAL" ]
+ if ! grep -q "$mname $symname .* add" "$mapdb" && \
+ [ "$secname" != "EXPERIMENTAL" ]
then
# Just inform users that non-experimenal
# symbols need to go through a deprecation
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-04-04 22:28 0% ` Eads, Gage
@ 2019-04-04 22:28 0% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-04-04 22:28 UTC (permalink / raw)
To: Ola Liljedahl, stephen
Cc: jerinj, mczekaj, nd, Ananyev, Konstantin, Richardson, Bruce, dev,
olivier.matz, arybchenko
> On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> > >
> > >
> > > On Mon, 18 Mar 2019 21:49:44 +0000
> > > "Eads, Gage" <gage.eads@intel.com> wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > > Friendly reminder that in order to get this feature into 19.08
> > > > (assuming
> > > folks also want that :)), the API deprecation notice needs to be
> > > merged into 19.05.
> > > >
> > > >
> > > > Thanks,
> > > > Gage
> > > Given the recent API/ABI stability discussion, this is the kind of
> > > patch that really needs to be examined and justified.
> > Can you point me to the discussion (assuming it was on the ML)? I'm
> > aware of Ferruh's changes to the docs, but not the discussion you
> referenced.
> >
> > The lock-free ring functionality itself is a valuable addition to
> > DPDK, primarily because it lacks the standard ring's non-preemptive
> > constraint. The non-preemptive constraint is important in an
> > application with both high priority, performance-sensitive data-plane
> > components and low-priority control-plane components. This was
> > important enough to warrant further clarification recently[1], and has
> > been a discussion topic for some time[2][3].
> >
> > The modified API, rte_ring_get_memsize(), was added to allow users to
> > initialize rings in separately allocated memory. This function isn't
> > called in DPDK's examples/apps/drivers, and a quick google search
> > didn't turn up any open source projects that call the function, so I
> > suspect that a majority of ring code uses rte_ring_create() instead of
> > rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface
> > change will affect a small percentage of DPDK users.
> >
> > As a straw-man counter-proposal, we could instead introduce a
> > lock-free specific function rte_lf_ring_get_memsize() that lock-free
> > ring users would call instead of rte_ring_get_memsize(). This would
> > avoid the API modification,
> > but:
> > - It's awkward to have one rte_lf_ring_* function and otherwise access
> > the lock-free ring through rte_ring_* functions.
> > - It's also easy to envision a user incorrectly calling
> > rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a
> > lock-free ring, since otherwise
> > rte_ring_* functions are used. DPDK would have no way to detect that
> > the allocated memory is too small, and if such a bug occurs it would
> > manifest itself as memory corruption.
> > - Changing rte_ring_get_memsize() to take a flags argument may be the
> > better long-term design, if another flag is introduced that likewise
> > uses a different ring size.
> >
> > Another approach is to break out the lock-free ring into a fully separate
> API.
> As in the RFC I posted: http://patches.dpdk.org/patch/50095/
> Cleaner API, simpler implementation.
>
> > One of the goals of my patchset was to allow applications to switch to lock-
> > free rings with minimal code change; I think the value of the lock-free ring
> > warrants such an approach.
>
> A noble goal but personally I think DPDK API's and implementations are
> getting more and more messy and thus difficult to use and difficult to
> maintain.
> Is it so much worse to have separate but structurally equivalent API's?
No -- I think both are valid options, with their own tradeoffs.
> Yes, blocking vs non-blocking can no longer be selected at runtime (startup
> time), I think this is the biggest limitation.
Run-time selection with the LF flag means we can easily re-use a large amount of pre-existing ring code -- e.g. the way the ring tests are re-purposed for lock-free rings in this patchset.
The implementation may not be as easily maintained, but we don't have to maintain LF-specific tests/benchmarks/etc.
Maintainers/tech leads, do y'all have a preference?
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
@ 2019-04-04 22:28 0% ` Eads, Gage
2019-04-04 22:28 0% ` Eads, Gage
0 siblings, 1 reply; 200+ results
From: Eads, Gage @ 2019-04-04 22:28 UTC (permalink / raw)
To: Ola Liljedahl, stephen
Cc: jerinj, mczekaj, nd, Ananyev, Konstantin, Richardson, Bruce, dev,
olivier.matz, arybchenko
> On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> > >
> > >
> > > On Mon, 18 Mar 2019 21:49:44 +0000
> > > "Eads, Gage" <gage.eads@intel.com> wrote:
> > >
> > > >
> > > > Hi all,
> > > >
> > > > Friendly reminder that in order to get this feature into 19.08
> > > > (assuming
> > > folks also want that :)), the API deprecation notice needs to be
> > > merged into 19.05.
> > > >
> > > >
> > > > Thanks,
> > > > Gage
> > > Given the recent API/ABI stability discussion, this is the kind of
> > > patch that really needs to be examined and justified.
> > Can you point me to the discussion (assuming it was on the ML)? I'm
> > aware of Ferruh's changes to the docs, but not the discussion you
> referenced.
> >
> > The lock-free ring functionality itself is a valuable addition to
> > DPDK, primarily because it lacks the standard ring's non-preemptive
> > constraint. The non-preemptive constraint is important in an
> > application with both high priority, performance-sensitive data-plane
> > components and low-priority control-plane components. This was
> > important enough to warrant further clarification recently[1], and has
> > been a discussion topic for some time[2][3].
> >
> > The modified API, rte_ring_get_memsize(), was added to allow users to
> > initialize rings in separately allocated memory. This function isn't
> > called in DPDK's examples/apps/drivers, and a quick google search
> > didn't turn up any open source projects that call the function, so I
> > suspect that a majority of ring code uses rte_ring_create() instead of
> > rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface
> > change will affect a small percentage of DPDK users.
> >
> > As a straw-man counter-proposal, we could instead introduce a
> > lock-free specific function rte_lf_ring_get_memsize() that lock-free
> > ring users would call instead of rte_ring_get_memsize(). This would
> > avoid the API modification,
> > but:
> > - It's awkward to have one rte_lf_ring_* function and otherwise access
> > the lock-free ring through rte_ring_* functions.
> > - It's also easy to envision a user incorrectly calling
> > rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a
> > lock-free ring, since otherwise
> > rte_ring_* functions are used. DPDK would have no way to detect that
> > the allocated memory is too small, and if such a bug occurs it would
> > manifest itself as memory corruption.
> > - Changing rte_ring_get_memsize() to take a flags argument may be the
> > better long-term design, if another flag is introduced that likewise
> > uses a different ring size.
> >
> > Another approach is to break out the lock-free ring into a fully separate
> API.
> As in the RFC I posted: http://patches.dpdk.org/patch/50095/
> Cleaner API, simpler implementation.
>
> > One of the goals of my patchset was to allow applications to switch to lock-
> > free rings with minimal code change; I think the value of the lock-free ring
> > warrants such an approach.
>
> A noble goal but personally I think DPDK API's and implementations are
> getting more and more messy and thus difficult to use and difficult to
> maintain.
> Is it so much worse to have separate but structurally equivalent API's?
No -- I think both are valid options, with their own tradeoffs.
> Yes, blocking vs non-blocking can no longer be selected at runtime (startup
> time), I think this is the biggest limitation.
Run-time selection with the LF flag means we can easily re-use a large amount of pre-existing ring code -- e.g. the way the ring tests are re-purposed for lock-free rings in this patchset.
The implementation may not be as easily maintained, but we don't have to maintain LF-specific tests/benchmarks/etc.
Maintainers/tech leads, do y'all have a preference?
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 20:13 8% ` Kevin Traynor
@ 2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 20:13 UTC (permalink / raw)
To: Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
>>
>>>
>>> My thoughts on the matter are:
>>> 1. I think we really need to do work to start hiding more of our data
>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>> the scope for ABI breaks.
>>> 2. Once done, I think we should commit to having an ABI break only in the
>>> rarest of circumstances, and only with very large justification. I want us
>>> to get to the point where DPDK releases can immediately be picked up by all
>>> linux distros and rolled out because they are ABI compatible.
>>>
>>
>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>> APIs at transition from experimental to core). Just as a way to get more
>> eyeballs and scrutiny on them.
>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>
We'll only find out if they are bad when they need ABI breaks later :-)
My point is a good way to avoid future ABI breaks is to have more
reviews on the APIs in the first place. Techboard approval might be one
way, or 3 acks or something else.
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
@ 2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 20:13 UTC (permalink / raw)
To: Wiles, Keith
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
On 04/04/2019 20:08, Wiles, Keith wrote:
>
>
>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> On 04/04/2019 11:54, Bruce Richardson wrote:
>> <snip>
>>
>>>
>>> My thoughts on the matter are:
>>> 1. I think we really need to do work to start hiding more of our data
>>> structures - like what Stephen's latest RFC does. This hiding should reduce
>>> the scope for ABI breaks.
>>> 2. Once done, I think we should commit to having an ABI break only in the
>>> rarest of circumstances, and only with very large justification. I want us
>>> to get to the point where DPDK releases can immediately be picked up by all
>>> linux distros and rolled out because they are ABI compatible.
>>>
>>
>> Maybe techboard should explicitly approve ABI breaks and new APIs (or
>> APIs at transition from experimental to core). Just as a way to get more
>> eyeballs and scrutiny on them.
>
> ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>>
We'll only find out if they are bad when they need ABI breaks later :-)
My point is a good way to avoid future ABI breaks is to have more
reviews on the APIs in the first place. Techboard approval might be one
way, or 3 acks or something else.
>>> I'm not sure I like the idea of planned ABI break releases - that strikes
>>> me as a plan where we end up with the same number of ABI breaks as before,
>>> just balled into one release.
>>>
>>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>>> case that each distro will only ship one version of DPDK, or is it possible
>>> that if we have ABI breaks, a distro will provide two copies of DPDK
>>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>>
>>
>> It would probably double validation and maintenance, so it would require
>> a lot of extra effort.
>>
>>>
>>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>>> ABI breaks, and having ABI breaks as a major event reserved only for
>>> massive rework changes, such as major mbuf changes, or new memory layout or
>>> similar.
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
> Regards,
> Keith
>
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 19:08 8% ` Wiles, Keith
@ 2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:29 4% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Wiles, Keith @ 2019-04-04 19:08 UTC (permalink / raw)
To: Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
> <snip>
>
>>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>>
>
> Maybe techboard should explicitly approve ABI breaks and new APIs (or
> APIs at transition from experimental to core). Just as a way to get more
> eyeballs and scrutiny on them.
ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>
>> I'm not sure I like the idea of planned ABI break releases - that strikes
>> me as a plan where we end up with the same number of ABI breaks as before,
>> just balled into one release.
>>
>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>> case that each distro will only ship one version of DPDK, or is it possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>
>
> It would probably double validation and maintenance, so it would require
> a lot of extra effort.
>
>>
>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
>
Regards,
Keith
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
@ 2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Wiles, Keith @ 2019-04-04 19:08 UTC (permalink / raw)
To: Kevin Traynor
Cc: Richardson, Bruce, Burakov, Anatoly, Ray Kinsella, dpdk-dev, techboard
> On Apr 4, 2019, at 11:56 AM, Kevin Traynor <ktraynor@redhat.com> wrote:
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
> <snip>
>
>>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>>
>
> Maybe techboard should explicitly approve ABI breaks and new APIs (or
> APIs at transition from experimental to core). Just as a way to get more
> eyeballs and scrutiny on them.
ABI breaks should be handled by the board. As for new APIs they are not so bad and they do not need to be approved by the board just handled in the normal way. For API changes (I guess that is ABI) needs to be handled by the board unless we use the version control and maintain both APIs for a while.
>
>> I'm not sure I like the idea of planned ABI break releases - that strikes
>> me as a plan where we end up with the same number of ABI breaks as before,
>> just balled into one release.
>>
>> Question for Kevin, Luca and others who look at distro-packaging: is it the
>> case that each distro will only ship one version of DPDK, or is it possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>>
>
> It would probably double validation and maintenance, so it would require
> a lot of extra effort.
>
>>
>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
>
Regards,
Keith
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:56 7% ` Kevin Traynor
@ 2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 16:56 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: Ray Kinsella, dev, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
<snip>
>
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
>
Maybe techboard should explicitly approve ABI breaks and new APIs (or
APIs at transition from experimental to core). Just as a way to get more
eyeballs and scrutiny on them.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
It would probably double validation and maintenance, so it would require
a lot of extra effort.
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
` (3 preceding siblings ...)
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
4 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 16:56 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: Ray Kinsella, dev, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
<snip>
>
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
>
Maybe techboard should explicitly approve ABI breaks and new APIs (or
APIs at transition from experimental to core). Just as a way to get more
eyeballs and scrutiny on them.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
It would probably double validation and maintenance, so it would require
a lot of extra effort.
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 16:37 4% ` Burakov, Anatoly
@ 2019-04-04 16:37 4% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 16:37 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On 04-Apr-19 4:51 PM, Stephen Hemminger wrote:
> On Thu, 4 Apr 2019 11:54:47 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> I would also like to propose "you get one ABI break" which means each
> API/ABI change must hide more infrastructure than the last. This is
> the "fool me once, ..." saying in API's.
>
> For example,
> the memory rework it would have been good if the structure of mempools etc
> were hidden inside EAL and not exposed. but as usual hindsight is 20/20
>
Mempools is not part of "memory rework" - it's a separate library built
on top of EAL's memory subsystem :) When i talk about "memory API's", i
mean memzone/malloc and friends, not mempool.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:37 4% ` Burakov, Anatoly
1 sibling, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-04-04 16:37 UTC (permalink / raw)
To: Stephen Hemminger, Bruce Richardson
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On 04-Apr-19 4:51 PM, Stephen Hemminger wrote:
> On Thu, 4 Apr 2019 11:54:47 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> I would also like to propose "you get one ABI break" which means each
> API/ABI change must hide more infrastructure than the last. This is
> the "fool me once, ..." saying in API's.
>
> For example,
> the memory rework it would have been good if the structure of mempools etc
> were hidden inside EAL and not exposed. but as usual hindsight is 20/20
>
Mempools is not part of "memory rework" - it's a separate library built
on top of EAL's memory subsystem :) When i talk about "memory API's", i
mean memzone/malloc and friends, not mempool.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 16:13 0% ` Ferruh Yigit
@ 2019-04-04 16:13 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-04 16:13 UTC (permalink / raw)
To: Xiaolong Ye, dev, Stephen Hemminger, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz
On 4/4/2019 9:51 AM, Xiaolong Ye wrote:
> Overview
> ========
>
> This patchset adds a new PMD driver for AF_XDP which is a proposed
> faster version of AF_PACKET interface in Linux, see below links [1] [2] for
> details of AF_XDP introduction:
>
> AF_XDP roadmap
> ==============
> - AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
> in libbpf has been merged in v5.1-rc1.
> - Now i40e and ixgbe drivers have supported zero copy mode.
>
> Change logs
> ===========
> v11:
>
> - fix the meson build issue
>
> v10:
>
> - refine the Makefile, remove RTE_KERNELDIR related CFLAGS
> - add a new internal file af_xdp_deps.h to handle the dependency for
> asm/barrier.h
> - fix a typo observed by Stephen
> - rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
> /usr/local/include/bpf
> - add libbpf build steps in af_xdp.rst
>
>
> v9:
> - adjust header files order according to Stephen's suggestion
>
> v8:
> - address Ferruh's comments on V7
> - replace posix_memalign with rte_memzone_reserve_aligned to get better
> performance
> - keep the first patch only as Oliver suggested as zero copy part
> implementation is still in suspense, we may provide the related patch
> later.
>
> v7:
> - mention mtu limitation in af_xdp.rst
> - fix the vdev name in af_xdp.rst
>
> V6:
>
> - remove the newline in AF_XDP_LOG definition to avoid double new lines
> issue.
> - rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
>
> V5:
>
> - disable AF_XDP pmd by default due to it requires kernel more recent
> than minimum kernel version supported by DPDK
> - address other review comments of Maxime
>
> V4:
>
> - change vdev name to net_af_xdp
> - adopt dynamic log type for all logging
> - Fix other style issues raised by Stephen
>
> V3:
>
> - Fix all style issues pointed by Stephen, Mattias, David.
> - Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
> mempool driver to handle the application use of AF_XDP's zero copy feature.
>
> V2:
> - Fix a NULL pointer reference crash issue
> - Fix txonly stop sending traffic in zc mode
> - Refactor rte_mbuf.c to avoid ABI breakage.
> - Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
>
> changes vs RFC sent by Qi last Aug:
>
> - Re-work base on AF_XDP's interface changes since the new libbpf has
> provided higher-level APIs that hide many of the details of the AP_XDP
> uapi. After the rework, it helps to reduce 300+ lines of code.
>
> - multi-queues is not supported due to current libbpf doesn't support
> multi-sockets on a single umem.
>
> - No extra steps to load xdp program manually, since the current behavior of
> libbpf would load a default xdp program when user calls xsk_socket__create.
> userspace application only needs to handle the cleanup.
>
> How to try
> ==========
>
> 1. take the kernel >= v5.1-rc1, build kernel and replace your host
> kernel with it.
>
> make sure you turn on XDP sockets when compiling
>
> Networking support -->
> Networking options -->
> [ * ] XDP sockets
>
> 2. build & install libbpf in tools/lib/bpf
>
> cd tools/lib/bpf
> make install_lib
> make install_headers
>
> 3. ethtool -L enp59s0f0 combined 1
>
> 4. extra step to build dpdk
>
> explicitly enable AF_XDP pmd by adding below line to
> config/common_linux
>
> CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
>
> 5. start testpmd
>
> ./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
>
> in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
> network traffics travel to queue 0 will be redirected to af_xdp socket.
>
> Xiaolong Ye (1):
> net/af_xdp: introduce AF XDP PMD driver
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
@ 2019-04-04 16:13 0% ` Ferruh Yigit
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-04 16:13 UTC (permalink / raw)
To: Xiaolong Ye, dev, Stephen Hemminger, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz
On 4/4/2019 9:51 AM, Xiaolong Ye wrote:
> Overview
> ========
>
> This patchset adds a new PMD driver for AF_XDP which is a proposed
> faster version of AF_PACKET interface in Linux, see below links [1] [2] for
> details of AF_XDP introduction:
>
> AF_XDP roadmap
> ==============
> - AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
> in libbpf has been merged in v5.1-rc1.
> - Now i40e and ixgbe drivers have supported zero copy mode.
>
> Change logs
> ===========
> v11:
>
> - fix the meson build issue
>
> v10:
>
> - refine the Makefile, remove RTE_KERNELDIR related CFLAGS
> - add a new internal file af_xdp_deps.h to handle the dependency for
> asm/barrier.h
> - fix a typo observed by Stephen
> - rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
> /usr/local/include/bpf
> - add libbpf build steps in af_xdp.rst
>
>
> v9:
> - adjust header files order according to Stephen's suggestion
>
> v8:
> - address Ferruh's comments on V7
> - replace posix_memalign with rte_memzone_reserve_aligned to get better
> performance
> - keep the first patch only as Oliver suggested as zero copy part
> implementation is still in suspense, we may provide the related patch
> later.
>
> v7:
> - mention mtu limitation in af_xdp.rst
> - fix the vdev name in af_xdp.rst
>
> V6:
>
> - remove the newline in AF_XDP_LOG definition to avoid double new lines
> issue.
> - rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
>
> V5:
>
> - disable AF_XDP pmd by default due to it requires kernel more recent
> than minimum kernel version supported by DPDK
> - address other review comments of Maxime
>
> V4:
>
> - change vdev name to net_af_xdp
> - adopt dynamic log type for all logging
> - Fix other style issues raised by Stephen
>
> V3:
>
> - Fix all style issues pointed by Stephen, Mattias, David.
> - Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
> mempool driver to handle the application use of AF_XDP's zero copy feature.
>
> V2:
> - Fix a NULL pointer reference crash issue
> - Fix txonly stop sending traffic in zc mode
> - Refactor rte_mbuf.c to avoid ABI breakage.
> - Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
>
> changes vs RFC sent by Qi last Aug:
>
> - Re-work base on AF_XDP's interface changes since the new libbpf has
> provided higher-level APIs that hide many of the details of the AP_XDP
> uapi. After the rework, it helps to reduce 300+ lines of code.
>
> - multi-queues is not supported due to current libbpf doesn't support
> multi-sockets on a single umem.
>
> - No extra steps to load xdp program manually, since the current behavior of
> libbpf would load a default xdp program when user calls xsk_socket__create.
> userspace application only needs to handle the cleanup.
>
> How to try
> ==========
>
> 1. take the kernel >= v5.1-rc1, build kernel and replace your host
> kernel with it.
>
> make sure you turn on XDP sockets when compiling
>
> Networking support -->
> Networking options -->
> [ * ] XDP sockets
>
> 2. build & install libbpf in tools/lib/bpf
>
> cd tools/lib/bpf
> make install_lib
> make install_headers
>
> 3. ethtool -L enp59s0f0 combined 1
>
> 4. extra step to build dpdk
>
> explicitly enable AF_XDP pmd by adding below line to
> config/common_linux
>
> CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
>
> 5. start testpmd
>
> ./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
>
> in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
> network traffics travel to queue 0 will be redirected to af_xdp socket.
>
> Xiaolong Ye (1):
> net/af_xdp: introduce AF XDP PMD driver
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 15:51 8% ` Stephen Hemminger
@ 2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-04 15:51 UTC (permalink / raw)
To: Bruce Richardson
Cc: Burakov, Anatoly, Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 4 Apr 2019 11:54:47 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
I would also like to propose "you get one ABI break" which means each
API/ABI change must hide more infrastructure than the last. This is
the "fool me once, ..." saying in API's.
For example,
the memory rework it would have been good if the structure of mempools etc
were hidden inside EAL and not exposed. but as usual hindsight is 20/20
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
` (2 preceding siblings ...)
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:56 7% ` Kevin Traynor
4 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-04 15:51 UTC (permalink / raw)
To: Bruce Richardson
Cc: Burakov, Anatoly, Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 4 Apr 2019 11:54:47 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
I would also like to propose "you get one ABI break" which means each
API/ABI change must hide more infrastructure than the last. This is
the "fool me once, ..." saying in API's.
For example,
the memory rework it would have been good if the structure of mempools etc
were hidden inside EAL and not exposed. but as usual hindsight is 20/20
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 14:07 9% ` Burakov, Anatoly
@ 2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 14:07 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson; +Cc: dev, Kevin Traynor, techboard
On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> Hi folks,
>>>>
> [SNIP]
>>>
>>> Hi Ray,
>>>
>>> My somewhat rambly 2 cents :)
>>>
>>> While i think some solution has to be found for the situation, we also have
>>> to balance this against speed of development and new features rollout.
>>>
>>> For example, let's consider what i am intimately familiar with - the memory
>>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>>> remain as ABI/API compatible as possible, but there were a couple of API
>>> calls that were removed, and there couldn't have been any replacements
>>> (these API's were exposing internal structures that shouldn't have been
>>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>>> because there was no way to do it without it (shared internal structures
>>> needed to change in part to support multiprocess).
>>>
>>> So, if i understand your proposal correctly, assuming a 2-year waiting
>>> period for the deprecation of core API's, you would essentially still be
>>> waiting for the memory rework to land for a year more. Moreover, even
>>> *after* it has landed, there was a continuous stream of improvements and
>>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>>> were my fault (as in, i could've foreseen the need for those changes, but
>>> didn't), but others came as a result of people using these new features in
>>> the wild and reporting issues/problems/suggestions - i am but one man, after
>>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>>> time to implement :)
>>>
>>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>>> keep backwards compatibility for this, or 2) keep two parallel versions of
>>> it. We also need to test all that, and, to be honest, one validation cycle
>>> for a release wouldn't be enough to figure out all of the kinks and
>>> implications of such a case. It was really great that memory rework has
>>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>>> i think everyone can say that it's in much better shape in 18.11 than it was
>>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>>> improvements would have slowed down significantly.
>>>
>>> Now, i understand that this is probably a highly exceptional case, but i'm
>>> sure that maintainers of other parts of DPDK will have their own examples of
>>> similar things happening.
>>>
>>> I have no idea what a proper solution would look like. Any "splitting" of
>>> the trees into "experimental" vs. "stable" will end up causing the same
>>> issue - people choose to use stable over experimental because, well, it's
>>> more stable, and new/experimental features don't get tested as much because
>>> no one runs the thing in the first place.
>>>
>>> TL;DR we have to be careful not to constrain the pace of
>>> development/bugfixing just for the sake of having a stable API/ABI :)
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project - it
>> should just start acting like it.
>
> I 100% agree.
>
> If you break your users stuff regularly enough, they will eventually
> start looking around for an alternative that doesn't break their stuff
> quiet so regularly.
>
> We often use the pace of innovation in DPDK as justification for ABI/API
> breakages, but that approach is a real rarity among the Open Source
> community. I can't think of any mature project off-hand that share's it.
>
> I would ask is Linux any less innovative because they offer a stable API
> and have an absolute commitment to never breaking userspace? Would Linux
> have ever been as popular as it is today it they broke userspace every
> quarter?
>
> They reality is that they (Linux) find workarounds and compromise
> because there is an uber-maintainer Linus who had a strong ethos from
> the start not to break their users stuff - we need the same ethos in DPDK.
>
>>
>> Now, in terms of features like the memory rework, that is indeed a case
>> that there was no alternative other than a massive ABI break. However, for
>> that rework there was a strong need for improvement in that area that we
>> can make the case for an ABI break to support it - and it is of a scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are of
>> that scale.
>
> I would also be inclined to agree with Bruce's points on memory rework
> was somewhat of an outlier, we don't see many like it.
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> The work that Anatoly describes removing APIs that exposed internal
> structures and Stephen H's RFC similarly are good examples of the kind
> of work required to prepare for this change. We need to take a good look
> at the API and reduce the number of unnecessary internal structures
> exposed.
>
> I never expected it going to to be a big bang - but is a definite
> direction we need to move towards over the next few release.
...in this case, we have to think long and hard about the fabled EAL
rework/split, and in general *specifying* what is it that we want to
support, and the use cases that we want to target. Right now there is a
huge mountain of technical debt and kludges and workarounds that has
accumulated over the years, and it exists precisely because "every
change breaks someone's workflow".
For example, just in memory subsystem alone, we have legacy mem, because
some use cases require huge amounts of contiguous memory, and not
everyone is using VFIO; there's all of the 32-bit related workarounds
and hacks; there's the single-file-segments stuff that could have been
the default if not for the fact that we support kernels that don't
support fallocate(); there are two different ways of doing in-memory
mode, because not all kernels support memfd's; there is a gargantuan
pile of workarounds (and "known issues", and just code in general) all
over the DPDK codebase just to support our multiprocess model and all of
the various warts that come with it.
In fact, i would even go as far as to say that *most* of EAL ABI breaks
have been due to the fact that we store data in shared memory because of
multiprocess - so there is simply no way we can change these internal
data structures without ABI breaks, because even if they're not exposed
through user-facing API, they are still exposed by virtue of secondary
processes basically having an ABI contract with primary process instances.
So, if we are to cement our core API - we have to make a concrete effort
to specify what goes and what stays, if we want it to be maintainable.
The DPDK 1.0 specification, if you will :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 14:07 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson; +Cc: dev, Kevin Traynor, techboard
On 04-Apr-19 1:52 PM, Ray Kinsella wrote:
>
>
> On 04/04/2019 11:54, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>>> Hi folks,
>>>>
> [SNIP]
>>>
>>> Hi Ray,
>>>
>>> My somewhat rambly 2 cents :)
>>>
>>> While i think some solution has to be found for the situation, we also have
>>> to balance this against speed of development and new features rollout.
>>>
>>> For example, let's consider what i am intimately familiar with - the memory
>>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>>> remain as ABI/API compatible as possible, but there were a couple of API
>>> calls that were removed, and there couldn't have been any replacements
>>> (these API's were exposing internal structures that shouldn't have been
>>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>>> because there was no way to do it without it (shared internal structures
>>> needed to change in part to support multiprocess).
>>>
>>> So, if i understand your proposal correctly, assuming a 2-year waiting
>>> period for the deprecation of core API's, you would essentially still be
>>> waiting for the memory rework to land for a year more. Moreover, even
>>> *after* it has landed, there was a continuous stream of improvements and
>>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>>> were my fault (as in, i could've foreseen the need for those changes, but
>>> didn't), but others came as a result of people using these new features in
>>> the wild and reporting issues/problems/suggestions - i am but one man, after
>>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>>> time to implement :)
>>>
>>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>>> keep backwards compatibility for this, or 2) keep two parallel versions of
>>> it. We also need to test all that, and, to be honest, one validation cycle
>>> for a release wouldn't be enough to figure out all of the kinks and
>>> implications of such a case. It was really great that memory rework has
>>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>>> i think everyone can say that it's in much better shape in 18.11 than it was
>>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>>> improvements would have slowed down significantly.
>>>
>>> Now, i understand that this is probably a highly exceptional case, but i'm
>>> sure that maintainers of other parts of DPDK will have their own examples of
>>> similar things happening.
>>>
>>> I have no idea what a proper solution would look like. Any "splitting" of
>>> the trees into "experimental" vs. "stable" will end up causing the same
>>> issue - people choose to use stable over experimental because, well, it's
>>> more stable, and new/experimental features don't get tested as much because
>>> no one runs the thing in the first place.
>>>
>>> TL;DR we have to be careful not to constrain the pace of
>>> development/bugfixing just for the sake of having a stable API/ABI :)
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project - it
>> should just start acting like it.
>
> I 100% agree.
>
> If you break your users stuff regularly enough, they will eventually
> start looking around for an alternative that doesn't break their stuff
> quiet so regularly.
>
> We often use the pace of innovation in DPDK as justification for ABI/API
> breakages, but that approach is a real rarity among the Open Source
> community. I can't think of any mature project off-hand that share's it.
>
> I would ask is Linux any less innovative because they offer a stable API
> and have an absolute commitment to never breaking userspace? Would Linux
> have ever been as popular as it is today it they broke userspace every
> quarter?
>
> They reality is that they (Linux) find workarounds and compromise
> because there is an uber-maintainer Linus who had a strong ethos from
> the start not to break their users stuff - we need the same ethos in DPDK.
>
>>
>> Now, in terms of features like the memory rework, that is indeed a case
>> that there was no alternative other than a massive ABI break. However, for
>> that rework there was a strong need for improvement in that area that we
>> can make the case for an ABI break to support it - and it is of a scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are of
>> that scale.
>
> I would also be inclined to agree with Bruce's points on memory rework
> was somewhat of an outlier, we don't see many like it.
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should reduce
>> the scope for ABI breaks.
>> 2. Once done, I think we should commit to having an ABI break only in the
>> rarest of circumstances, and only with very large justification. I want us
>> to get to the point where DPDK releases can immediately be picked up by all
>> linux distros and rolled out because they are ABI compatible.
>
> The work that Anatoly describes removing APIs that exposed internal
> structures and Stephen H's RFC similarly are good examples of the kind
> of work required to prepare for this change. We need to take a good look
> at the API and reduce the number of unnecessary internal structures
> exposed.
>
> I never expected it going to to be a big bang - but is a definite
> direction we need to move towards over the next few release.
...in this case, we have to think long and hard about the fabled EAL
rework/split, and in general *specifying* what is it that we want to
support, and the use cases that we want to target. Right now there is a
huge mountain of technical debt and kludges and workarounds that has
accumulated over the years, and it exists precisely because "every
change breaks someone's workflow".
For example, just in memory subsystem alone, we have legacy mem, because
some use cases require huge amounts of contiguous memory, and not
everyone is using VFIO; there's all of the 32-bit related workarounds
and hacks; there's the single-file-segments stuff that could have been
the default if not for the fact that we support kernels that don't
support fallocate(); there are two different ways of doing in-memory
mode, because not all kernels support memfd's; there is a gargantuan
pile of workarounds (and "known issues", and just code in general) all
over the DPDK codebase just to support our multiprocess model and all of
the various warts that come with it.
In fact, i would even go as far as to say that *most* of EAL ABI breaks
have been due to the fact that we store data in shared memory because of
multiprocess - so there is simply no way we can change these internal
data structures without ABI breaks, because even if they're not exposed
through user-facing API, they are still exposed by virtue of secondary
processes basically having an ABI contract with primary process instances.
So, if we are to cement our core API - we have to make a concrete effort
to specify what goes and what stays, if we want it to be maintainable.
The DPDK 1.0 specification, if you will :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:21 4% ` Luca Boccassi
@ 2019-04-04 13:21 4% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 13:21 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 14:05 +0100, Ray Kinsella wrote:
> > > Question for Kevin, Luca and others who look at distro-packaging:
> > > is
> > > it the
> > > case that each distro will only ship one version of DPDK, or is
> > > it
> > > possible
> > > that if we have ABI breaks, a distro will provide two copies of
> > > DPDK
> > > simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
> >
> > We can ship multiple versions, although it's more work so there
> > should
> > be a good reason to do it.
>
> Well you already kind of do right.
> You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9
> backports.
Yes indeed - backports has a different policy and is not part of
"Debian main" - for example, stability and security support are not
guaranteed. Also there is no guarantee of compatibility of co-
installability - while you can have the individual libraries from each
version at the same time, you can't have both libdpdk-dev packages
which are necessary to build an application. So you have to choose and
install either libdpdk-dev=16.11 or libdpdk-dev=18.11.
It is possible to have multiple versions in the same archive at the
same time, and with multiple -dev packages, and that's what I meant
when I mentioned it was more work.
> > At the moment in Debian and Ubuntu we don't,
> > and we tend to ship whatever the latest LTS version is at the
> > distro
> > freeze milestone - for example Debian 10 which will be released
> > soon
> > (TM) will have 18.11.0.
>
> Presumably when 19.11 arrives, it will land in Debian 10 backports
> similarly.
>
> I assume anything that lands in backports is not guaranteed to be ABI
> compatible with stable?
Yes, there's no guarantee.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-04 13:21 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 14:05 +0100, Ray Kinsella wrote:
> > > Question for Kevin, Luca and others who look at distro-packaging:
> > > is
> > > it the
> > > case that each distro will only ship one version of DPDK, or is
> > > it
> > > possible
> > > that if we have ABI breaks, a distro will provide two copies of
> > > DPDK
> > > simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
> >
> > We can ship multiple versions, although it's more work so there
> > should
> > be a good reason to do it.
>
> Well you already kind of do right.
> You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9
> backports.
Yes indeed - backports has a different policy and is not part of
"Debian main" - for example, stability and security support are not
guaranteed. Also there is no guarantee of compatibility of co-
installability - while you can have the individual libraries from each
version at the same time, you can't have both libdpdk-dev packages
which are necessary to build an application. So you have to choose and
install either libdpdk-dev=16.11 or libdpdk-dev=18.11.
It is possible to have multiple versions in the same archive at the
same time, and with multiple -dev packages, and that's what I meant
when I mentioned it was more work.
> > At the moment in Debian and Ubuntu we don't,
> > and we tend to ship whatever the latest LTS version is at the
> > distro
> > freeze milestone - for example Debian 10 which will be released
> > soon
> > (TM) will have 18.11.0.
>
> Presumably when 19.11 arrives, it will land in Debian 10 backports
> similarly.
>
> I assume anything that lands in backports is not guaranteed to be ABI
> compatible with stable?
Yes, there's no guarantee.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 13:16 7% ` Ray Kinsella
@ 2019-04-04 13:16 7% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:16 UTC (permalink / raw)
To: Kevin Traynor, dev, techboard
On 04/04/2019 10:47, Kevin Traynor wrote:
> On 03/04/2019 16:42, Ray Kinsella wrote:
>> Hi folks,
>>
[SNIP]
>>
>> The DPDK ABI churn has the following affects for users:-
>>
>> 1. The churn obliges users of DPDK to commit to a constant
>> re-integration and re-validation effort for new versions of DPDK. This
>> effort from their perspective may not add value to their consuming
>> project, particular if they are only updating to "stay current".
>> 2. The churn encourages users of DPDK to slip versions, putting off
>> reintegration to later, building up technical debt and causing their
>> projects to miss support for new hardware or features.
>> 3. It makes DPDK different to almost every other system library and
>> framework that an operating systems might ship. This makes DPDK trickier
>> to dynamically link against, package and maintain for OS maintainers.
>>
>
> +1
>
>> In order to address this issue, I have put together the minimal set of
>> concrete proposals below for discussion at the Technical Board next
>> Wednesday.
>>
>> I wanted to share this, as these might not yet be the right proposals,
>> however I am putting them out there for feedback to start the discussion.
>>
>> Thanks,
>>
>> Ray K
>>
>>
>> Experimental API
>> 1. APIs designated as experimental are not considered part of the ABI
>> and may change without warning at any time.
>> 2. APIs designated as experimental must be marked depreciated for a
>> least one quarterly release before removal.
>> 3. APIs designated as experimental will no longer automatically graduate
>> to core after one release, they may stay experimental until their author
>> and the maintainer agree that graduation is appropriate.
>>
>
> I don't think they automatically graduate in the current scheme, so it
> would seem to be no change to the process.
You are correct ...
"New APIs will be marked as experimental for at least one release to
allow any issues found by users of the new API to be fixed quickly."
https://doc.dpdk.org/guides-18.11/contributing/versioning.html
>
> One thing to note is that in the current experimental API scheme those
> API are tagged as deprecated which can cause problems with application
> build/CI if they are used. But this is more related to implementation
> rather than the classification indicating the API may change. It might
> need to change if there was a trend for keeping API as experimental for
> a longer time.
Others have said this to me also - we need to make experimental less
scary - so people won't be quiet as eager to remove the tag. Depreciated
should stay scary however.
>
>> Core API (non-experimental API)
>> 4. APIs designated as core must be depreciated for a least two years
>> before removal, to facilitate the continued compatibility with LTS
>> releases. A final removal notice will be published to the DPDK Mailing
>> List, and if there are no strong objections only then an API may be
>> removed.
>> 5. APIs designated as core may be changed as follows:-
>
>> 5.a The change proposer must demonstrated that the change has a
>> supporting use case and could not be achieved in any other way.
>
> I agree with the sentiment but it needs real buy in from authors.
Well I would say it needs real buy in from the Maintainers, at the end
of the day they are the gatekeepers in this instance.
> Otherwise the burden falls on the reviewer to spend time
> exploring/finding a way not to change the API.
I think most of the time, Maintainers will have a good sense of when a
ABI/API change is actually warranted.
>
>> 5.b ABI version compatibility must be retained, as described below.
>>
>> Shared Libraries
>> 6. DPDK will move to shared libraries & dynamic linking by default, to
>> accommodate greater use of ABI versioning by DPDK consumers.
>>
>> ABI Versioning
>> 7. New quarterly releases of DPDK will remain ABI compatible with the
>> most recent DPDK LTS release.
>> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
>> 8. New DPDK LTS releases will remain ABI compatible with the previous
>> two DPDK LTS releases.
>> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
>> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
>> 8. & 9. will be achieved with ABI symbol versioning.
>>
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
@ 2019-04-04 13:16 7% ` Ray Kinsella
2019-04-04 13:16 7% ` Ray Kinsella
1 sibling, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-04 13:16 UTC (permalink / raw)
To: Kevin Traynor, dev, techboard
On 04/04/2019 10:47, Kevin Traynor wrote:
> On 03/04/2019 16:42, Ray Kinsella wrote:
>> Hi folks,
>>
[SNIP]
>>
>> The DPDK ABI churn has the following affects for users:-
>>
>> 1. The churn obliges users of DPDK to commit to a constant
>> re-integration and re-validation effort for new versions of DPDK. This
>> effort from their perspective may not add value to their consuming
>> project, particular if they are only updating to "stay current".
>> 2. The churn encourages users of DPDK to slip versions, putting off
>> reintegration to later, building up technical debt and causing their
>> projects to miss support for new hardware or features.
>> 3. It makes DPDK different to almost every other system library and
>> framework that an operating systems might ship. This makes DPDK trickier
>> to dynamically link against, package and maintain for OS maintainers.
>>
>
> +1
>
>> In order to address this issue, I have put together the minimal set of
>> concrete proposals below for discussion at the Technical Board next
>> Wednesday.
>>
>> I wanted to share this, as these might not yet be the right proposals,
>> however I am putting them out there for feedback to start the discussion.
>>
>> Thanks,
>>
>> Ray K
>>
>>
>> Experimental API
>> 1. APIs designated as experimental are not considered part of the ABI
>> and may change without warning at any time.
>> 2. APIs designated as experimental must be marked depreciated for a
>> least one quarterly release before removal.
>> 3. APIs designated as experimental will no longer automatically graduate
>> to core after one release, they may stay experimental until their author
>> and the maintainer agree that graduation is appropriate.
>>
>
> I don't think they automatically graduate in the current scheme, so it
> would seem to be no change to the process.
You are correct ...
"New APIs will be marked as experimental for at least one release to
allow any issues found by users of the new API to be fixed quickly."
https://doc.dpdk.org/guides-18.11/contributing/versioning.html
>
> One thing to note is that in the current experimental API scheme those
> API are tagged as deprecated which can cause problems with application
> build/CI if they are used. But this is more related to implementation
> rather than the classification indicating the API may change. It might
> need to change if there was a trend for keeping API as experimental for
> a longer time.
Others have said this to me also - we need to make experimental less
scary - so people won't be quiet as eager to remove the tag. Depreciated
should stay scary however.
>
>> Core API (non-experimental API)
>> 4. APIs designated as core must be depreciated for a least two years
>> before removal, to facilitate the continued compatibility with LTS
>> releases. A final removal notice will be published to the DPDK Mailing
>> List, and if there are no strong objections only then an API may be
>> removed.
>> 5. APIs designated as core may be changed as follows:-
>
>> 5.a The change proposer must demonstrated that the change has a
>> supporting use case and could not be achieved in any other way.
>
> I agree with the sentiment but it needs real buy in from authors.
Well I would say it needs real buy in from the Maintainers, at the end
of the day they are the gatekeepers in this instance.
> Otherwise the burden falls on the reviewer to spend time
> exploring/finding a way not to change the API.
I think most of the time, Maintainers will have a good sense of when a
ABI/API change is actually warranted.
>
>> 5.b ABI version compatibility must be retained, as described below.
>>
>> Shared Libraries
>> 6. DPDK will move to shared libraries & dynamic linking by default, to
>> accommodate greater use of ABI versioning by DPDK consumers.
>>
>> ABI Versioning
>> 7. New quarterly releases of DPDK will remain ABI compatible with the
>> most recent DPDK LTS release.
>> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
>> 8. New DPDK LTS releases will remain ABI compatible with the previous
>> two DPDK LTS releases.
>> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
>> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
>> 8. & 9. will be achieved with ABI symbol versioning.
>>
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:10 8% ` Bruce Richardson
@ 2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 13:10 UTC (permalink / raw)
To: Ray Kinsella
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>
>
> On 04/04/2019 13:02, Luca Boccassi wrote:
> > On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >>>
> >>
> >> Actually, I think we *do* need to constrain the pace of development
> >> for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project -
> >> it
> >> should just start acting like it.
> >>
> >> Now, in terms of features like the memory rework, that is indeed a
> >> case
> >> that there was no alternative other than a massive ABI break.
> >> However, for
> >> that rework there was a strong need for improvement in that area that
> >> we
> >> can make the case for an ABI break to support it - and it is of a
> >> scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are
> >> of
> >> that scale.
> >
> > Fully agree.
> >
> > It's normal for new project, big and small, to start without a
> > stability promise as development ramps up, and then steer toward
> > stability as the user base grows. Sometimes the switch is made explicit
> > by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> > I don't think we crossed that boundary yet in this project, and I
> > believe that's the main question Ray was trying to raise: has the time
> > finally come for DPDK to do this phase shift?
>
> Yes - we never had a 1.0, where we cut an API and stood behind it
> similar to GStreamer. There a number of reasons why this happened not
> worth going into, however you make the point very well Luca - this phase
> shift is long over due.
>
> >
> > Of course it comes with a price for all developers, and that's again
> > common.
>
> Agreed - nothing is for free.
> The question is this something we value and is it something worth doing.
>
> >
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should
> >> reduce
> >> the scope for ABI breaks.
> >
> > Yes, I'm a big fan of accessors and opaque structs.
>
> +1, me too.
>
I would be too, with certain exceptions - rte_mbuf for one. Any structures
that are used by applications cannot be made opaque, as apps do not want to
pay the cost of having to call a function every time they want to access
something from one of those structures.
Thankfully for us, we have plenty of other structures that we can work on
in the meantime that can be made private to avoid ABI breaks! :-) I suggest
we work through those first, allowing us to hone our ABI-break avoidance
skills.
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
@ 2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 13:10 UTC (permalink / raw)
To: Ray Kinsella
Cc: Luca Boccassi, Burakov, Anatoly, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote:
>
>
> On 04/04/2019 13:02, Luca Boccassi wrote:
> > On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> >> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> >>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> [SNIP]
> >>>
> >>
> >> Actually, I think we *do* need to constrain the pace of development
> >> for the
> >> sake of ABI stability. At this stage DPDK has been around for quite a
> >> number of years and so should be considered a fairly mature project -
> >> it
> >> should just start acting like it.
> >>
> >> Now, in terms of features like the memory rework, that is indeed a
> >> case
> >> that there was no alternative other than a massive ABI break.
> >> However, for
> >> that rework there was a strong need for improvement in that area that
> >> we
> >> can make the case for an ABI break to support it - and it is of a
> >> scale
> >> that nothing other than an ABI change would do. For other areas and
> >> examples, I doubt there are many in the last couple of years that are
> >> of
> >> that scale.
> >
> > Fully agree.
> >
> > It's normal for new project, big and small, to start without a
> > stability promise as development ramps up, and then steer toward
> > stability as the user base grows. Sometimes the switch is made explicit
> > by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> > I don't think we crossed that boundary yet in this project, and I
> > believe that's the main question Ray was trying to raise: has the time
> > finally come for DPDK to do this phase shift?
>
> Yes - we never had a 1.0, where we cut an API and stood behind it
> similar to GStreamer. There a number of reasons why this happened not
> worth going into, however you make the point very well Luca - this phase
> shift is long over due.
>
> >
> > Of course it comes with a price for all developers, and that's again
> > common.
>
> Agreed - nothing is for free.
> The question is this something we value and is it something worth doing.
>
> >
> >> My thoughts on the matter are:
> >> 1. I think we really need to do work to start hiding more of our data
> >> structures - like what Stephen's latest RFC does. This hiding should
> >> reduce
> >> the scope for ABI breaks.
> >
> > Yes, I'm a big fan of accessors and opaque structs.
>
> +1, me too.
>
I would be too, with certain exceptions - rte_mbuf for one. Any structures
that are used by applications cannot be made opaque, as apps do not want to
pay the cost of having to call a function every time they want to access
something from one of those structures.
Thankfully for us, we have plenty of other structures that we can work on
in the meantime that can be made private to avoid ABI breaks! :-) I suggest
we work through those first, allowing us to hone our ABI-break avoidance
skills.
/Bruce
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 13:05 7% ` Ray Kinsella
@ 2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:21 4% ` Luca Boccassi
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:05 UTC (permalink / raw)
To: Luca Boccassi, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On 04/04/2019 13:02, Luca Boccassi wrote:
> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development
>> for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project -
>> it
>> should just start acting like it.
>>
>> Now, in terms of features like the memory rework, that is indeed a
>> case
>> that there was no alternative other than a massive ABI break.
>> However, for
>> that rework there was a strong need for improvement in that area that
>> we
>> can make the case for an ABI break to support it - and it is of a
>> scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are
>> of
>> that scale.
>
> Fully agree.
>
> It's normal for new project, big and small, to start without a
> stability promise as development ramps up, and then steer toward
> stability as the user base grows. Sometimes the switch is made explicit
> by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> I don't think we crossed that boundary yet in this project, and I
> believe that's the main question Ray was trying to raise: has the time
> finally come for DPDK to do this phase shift?
Yes - we never had a 1.0, where we cut an API and stood behind it
similar to GStreamer. There a number of reasons why this happened not
worth going into, however you make the point very well Luca - this phase
shift is long over due.
>
> Of course it comes with a price for all developers, and that's again
> common.
Agreed - nothing is for free.
The question is this something we value and is it something worth doing.
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should
>> reduce
>> the scope for ABI breaks.
>
> Yes, I'm a big fan of accessors and opaque structs.
+1, me too.
>
>> 2. Once done, I think we should commit to having an ABI break only in
>> the
>> rarest of circumstances, and only with very large justification. I
>> want us
>> to get to the point where DPDK releases can immediately be picked up
>> by all
>> linux distros and rolled out because they are ABI compatible.
>>
>> I'm not sure I like the idea of planned ABI break releases - that
>> strikes
>> me as a plan where we end up with the same number of ABI breaks as
>> before,
>> just balled into one release.
>
> I think that was intended as a compromise, especially as we move from
> one model to the other, and more of a "if a breakage has to happen, it
> must be in the X release" rather than "let's always break in the X
> release" :-)
>
>> Question for Kevin, Luca and others who look at distro-packaging: is
>> it the
>> case that each distro will only ship one version of DPDK, or is it
>> possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
> We can ship multiple versions, although it's more work so there should
> be a good reason to do it.
Well you already kind of do right.
You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9 backports.
> At the moment in Debian and Ubuntu we don't,
> and we tend to ship whatever the latest LTS version is at the distro
> freeze milestone - for example Debian 10 which will be released soon
> (TM) will have 18.11.0.
Presumably when 19.11 arrives, it will land in Debian 10 backports
similarly.
I assume anything that lands in backports is not guaranteed to be ABI
compatible with stable?
>
>> So, in short, I'm generally in favour of a zero-tolerance approach
>> for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory
>> layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 13:05 UTC (permalink / raw)
To: Luca Boccassi, Bruce Richardson, Burakov, Anatoly
Cc: dev, Kevin Traynor, techboard
On 04/04/2019 13:02, Luca Boccassi wrote:
> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
[SNIP]
>>>
>>
>> Actually, I think we *do* need to constrain the pace of development
>> for the
>> sake of ABI stability. At this stage DPDK has been around for quite a
>> number of years and so should be considered a fairly mature project -
>> it
>> should just start acting like it.
>>
>> Now, in terms of features like the memory rework, that is indeed a
>> case
>> that there was no alternative other than a massive ABI break.
>> However, for
>> that rework there was a strong need for improvement in that area that
>> we
>> can make the case for an ABI break to support it - and it is of a
>> scale
>> that nothing other than an ABI change would do. For other areas and
>> examples, I doubt there are many in the last couple of years that are
>> of
>> that scale.
>
> Fully agree.
>
> It's normal for new project, big and small, to start without a
> stability promise as development ramps up, and then steer toward
> stability as the user base grows. Sometimes the switch is made explicit
> by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
> I don't think we crossed that boundary yet in this project, and I
> believe that's the main question Ray was trying to raise: has the time
> finally come for DPDK to do this phase shift?
Yes - we never had a 1.0, where we cut an API and stood behind it
similar to GStreamer. There a number of reasons why this happened not
worth going into, however you make the point very well Luca - this phase
shift is long over due.
>
> Of course it comes with a price for all developers, and that's again
> common.
Agreed - nothing is for free.
The question is this something we value and is it something worth doing.
>
>> My thoughts on the matter are:
>> 1. I think we really need to do work to start hiding more of our data
>> structures - like what Stephen's latest RFC does. This hiding should
>> reduce
>> the scope for ABI breaks.
>
> Yes, I'm a big fan of accessors and opaque structs.
+1, me too.
>
>> 2. Once done, I think we should commit to having an ABI break only in
>> the
>> rarest of circumstances, and only with very large justification. I
>> want us
>> to get to the point where DPDK releases can immediately be picked up
>> by all
>> linux distros and rolled out because they are ABI compatible.
>>
>> I'm not sure I like the idea of planned ABI break releases - that
>> strikes
>> me as a plan where we end up with the same number of ABI breaks as
>> before,
>> just balled into one release.
>
> I think that was intended as a compromise, especially as we move from
> one model to the other, and more of a "if a breakage has to happen, it
> must be in the X release" rather than "let's always break in the X
> release" :-)
>
>> Question for Kevin, Luca and others who look at distro-packaging: is
>> it the
>> case that each distro will only ship one version of DPDK, or is it
>> possible
>> that if we have ABI breaks, a distro will provide two copies of DPDK
>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
> We can ship multiple versions, although it's more work so there should
> be a good reason to do it.
Well you already kind of do right.
You ship 16.11.8 with Debian 9 and then 18.11 with Debian 9 backports.
> At the moment in Debian and Ubuntu we don't,
> and we tend to ship whatever the latest LTS version is at the distro
> freeze milestone - for example Debian 10 which will be released soon
> (TM) will have 18.11.0.
Presumably when 19.11 arrives, it will land in Debian 10 backports
similarly.
I assume anything that lands in backports is not guaranteed to be ABI
compatible with stable?
>
>> So, in short, I'm generally in favour of a zero-tolerance approach
>> for DPDK
>> ABI breaks, and having ABI breaks as a major event reserved only for
>> massive rework changes, such as major mbuf changes, or new memory
>> layout or
>> similar.
>>
>> Regards,
>> /Bruce
>>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:52 7% ` Ray Kinsella
@ 2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 12:52 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: dev, Kevin Traynor, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> Hi folks,
>>>
[SNIP]
>>
>> Hi Ray,
>>
>> My somewhat rambly 2 cents :)
>>
>> While i think some solution has to be found for the situation, we also have
>> to balance this against speed of development and new features rollout.
>>
>> For example, let's consider what i am intimately familiar with - the memory
>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>> remain as ABI/API compatible as possible, but there were a couple of API
>> calls that were removed, and there couldn't have been any replacements
>> (these API's were exposing internal structures that shouldn't have been
>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>> because there was no way to do it without it (shared internal structures
>> needed to change in part to support multiprocess).
>>
>> So, if i understand your proposal correctly, assuming a 2-year waiting
>> period for the deprecation of core API's, you would essentially still be
>> waiting for the memory rework to land for a year more. Moreover, even
>> *after* it has landed, there was a continuous stream of improvements and
>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>> were my fault (as in, i could've foreseen the need for those changes, but
>> didn't), but others came as a result of people using these new features in
>> the wild and reporting issues/problems/suggestions - i am but one man, after
>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>> time to implement :)
>>
>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>> keep backwards compatibility for this, or 2) keep two parallel versions of
>> it. We also need to test all that, and, to be honest, one validation cycle
>> for a release wouldn't be enough to figure out all of the kinks and
>> implications of such a case. It was really great that memory rework has
>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>> i think everyone can say that it's in much better shape in 18.11 than it was
>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>> improvements would have slowed down significantly.
>>
>> Now, i understand that this is probably a highly exceptional case, but i'm
>> sure that maintainers of other parts of DPDK will have their own examples of
>> similar things happening.
>>
>> I have no idea what a proper solution would look like. Any "splitting" of
>> the trees into "experimental" vs. "stable" will end up causing the same
>> issue - people choose to use stable over experimental because, well, it's
>> more stable, and new/experimental features don't get tested as much because
>> no one runs the thing in the first place.
>>
>> TL;DR we have to be careful not to constrain the pace of
>> development/bugfixing just for the sake of having a stable API/ABI :)
>>
>
> Actually, I think we *do* need to constrain the pace of development for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project - it
> should just start acting like it.
I 100% agree.
If you break your users stuff regularly enough, they will eventually
start looking around for an alternative that doesn't break their stuff
quiet so regularly.
We often use the pace of innovation in DPDK as justification for ABI/API
breakages, but that approach is a real rarity among the Open Source
community. I can't think of any mature project off-hand that share's it.
I would ask is Linux any less innovative because they offer a stable API
and have an absolute commitment to never breaking userspace? Would Linux
have ever been as popular as it is today it they broke userspace every
quarter?
They reality is that they (Linux) find workarounds and compromise
because there is an uber-maintainer Linus who had a strong ethos from
the start not to break their users stuff - we need the same ethos in DPDK.
>
> Now, in terms of features like the memory rework, that is indeed a case
> that there was no alternative other than a massive ABI break. However, for
> that rework there was a strong need for improvement in that area that we
> can make the case for an ABI break to support it - and it is of a scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are of
> that scale.
I would also be inclined to agree with Bruce's points on memory rework
was somewhat of an outlier, we don't see many like it.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
The work that Anatoly describes removing APIs that exposed internal
structures and Stephen H's RFC similarly are good examples of the kind
of work required to prepare for this change. We need to take a good look
at the API and reduce the number of unnecessary internal structures
exposed.
I never expected it going to to be a big bang - but is a definite
direction we need to move towards over the next few release.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
I agree, with this approach you just delaying the evil day and when that
day comes it will 10-times more painful. This is no substitute for a
don't break our users stuff ethos.
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:56 7% ` Kevin Traynor
4 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-04 12:52 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly; +Cc: dev, Kevin Traynor, techboard
On 04/04/2019 11:54, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
>>> Hi folks,
>>>
[SNIP]
>>
>> Hi Ray,
>>
>> My somewhat rambly 2 cents :)
>>
>> While i think some solution has to be found for the situation, we also have
>> to balance this against speed of development and new features rollout.
>>
>> For example, let's consider what i am intimately familiar with - the memory
>> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
>> remain as ABI/API compatible as possible, but there were a couple of API
>> calls that were removed, and there couldn't have been any replacements
>> (these API's were exposing internal structures that shouldn't have been
>> exposed in the first place), and 18.05 also broke the ABI compatibility,
>> because there was no way to do it without it (shared internal structures
>> needed to change in part to support multiprocess).
>>
>> So, if i understand your proposal correctly, assuming a 2-year waiting
>> period for the deprecation of core API's, you would essentially still be
>> waiting for the memory rework to land for a year more. Moreover, even
>> *after* it has landed, there was a continuous stream of improvements and
>> bugfixes, some of which has broke ABI compatibility as well. Some of them
>> were my fault (as in, i could've foreseen the need for those changes, but
>> didn't), but others came as a result of people using these new features in
>> the wild and reporting issues/problems/suggestions - i am but one man, after
>> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
>> time to implement :)
>>
>> Since this rework goes right at the heart of DPDK (arguably there isn't a
>> more "core" API than memory!), there is no (sane) way in the universe to 1)
>> keep backwards compatibility for this, or 2) keep two parallel versions of
>> it. We also need to test all that, and, to be honest, one validation cycle
>> for a release wouldn't be enough to figure out all of the kinks and
>> implications of such a case. It was really great that memory rework has
>> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
>> i think everyone can say that it's in much better shape in 18.11 than it was
>> in 18.05, but if we couldn't do an ABI break here or there, this rate of
>> improvements would have slowed down significantly.
>>
>> Now, i understand that this is probably a highly exceptional case, but i'm
>> sure that maintainers of other parts of DPDK will have their own examples of
>> similar things happening.
>>
>> I have no idea what a proper solution would look like. Any "splitting" of
>> the trees into "experimental" vs. "stable" will end up causing the same
>> issue - people choose to use stable over experimental because, well, it's
>> more stable, and new/experimental features don't get tested as much because
>> no one runs the thing in the first place.
>>
>> TL;DR we have to be careful not to constrain the pace of
>> development/bugfixing just for the sake of having a stable API/ABI :)
>>
>
> Actually, I think we *do* need to constrain the pace of development for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project - it
> should just start acting like it.
I 100% agree.
If you break your users stuff regularly enough, they will eventually
start looking around for an alternative that doesn't break their stuff
quiet so regularly.
We often use the pace of innovation in DPDK as justification for ABI/API
breakages, but that approach is a real rarity among the Open Source
community. I can't think of any mature project off-hand that share's it.
I would ask is Linux any less innovative because they offer a stable API
and have an absolute commitment to never breaking userspace? Would Linux
have ever been as popular as it is today it they broke userspace every
quarter?
They reality is that they (Linux) find workarounds and compromise
because there is an uber-maintainer Linus who had a strong ethos from
the start not to break their users stuff - we need the same ethos in DPDK.
>
> Now, in terms of features like the memory rework, that is indeed a case
> that there was no alternative other than a massive ABI break. However, for
> that rework there was a strong need for improvement in that area that we
> can make the case for an ABI break to support it - and it is of a scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are of
> that scale.
I would also be inclined to agree with Bruce's points on memory rework
was somewhat of an outlier, we don't see many like it.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should reduce
> the scope for ABI breaks.
> 2. Once done, I think we should commit to having an ABI break only in the
> rarest of circumstances, and only with very large justification. I want us
> to get to the point where DPDK releases can immediately be picked up by all
> linux distros and rolled out because they are ABI compatible.
The work that Anatoly describes removing APIs that exposed internal
structures and Stephen H's RFC similarly are good examples of the kind
of work required to prepare for this change. We need to take a good look
at the API and reduce the number of unnecessary internal structures
exposed.
I never expected it going to to be a big bang - but is a definite
direction we need to move towards over the next few release.
> I'm not sure I like the idea of planned ABI break releases - that strikes
> me as a plan where we end up with the same number of ABI breaks as before,
> just balled into one release.
>
I agree, with this approach you just delaying the evil day and when that
day comes it will 10-times more painful. This is no substitute for a
don't break our users stuff ethos.
> Question for Kevin, Luca and others who look at distro-packaging: is it the
> case that each distro will only ship one version of DPDK, or is it possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
>
>
> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory layout or
> similar.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 12:02 4% ` Luca Boccassi
@ 2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 12:02 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > > Hi folks,
> > >
> > > Recently I started a discussion with the DPDK Technical Board on
> > > DPDK
> > > ABI/API stability. This was born out informal feedback I had
> > > received
> > > from a number of users of DPDK about ABI churn. In turn this
> > > feedback
> > > then prompted an ABI analysis of DPDK using tools from abi-
> > > laboratory.
> > >
> > > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> > >
> > >
> > > I guess the short story is that DPDK ABI hasn't really settled
> > > down as
> > > the project has matured. If you take a look at the “Backward
> > > Compat.”
> > > column which measures ABI compatibility compared to the previous
> > > releases, you will see significant churn in the ABI over
> > > successive
> > > releases since v16.04.
> > >
> > > Now compare DPDK to GStreamer as an example of a very mature
> > > project
> > > with a similar intent, a framework for building applications, and
> > > which
> > > enjoys a very stable API.
> > >
> > > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> > >
> > >
> > > The DPDK ABI churn has the following affects for users:-
> > >
> > > 1. The churn obliges users of DPDK to commit to a constant
> > > re-integration and re-validation effort for new versions of DPDK.
> > > This
> > > effort from their perspective may not add value to their
> > > consuming
> > > project, particular if they are only updating to "stay current".
> > > 2. The churn encourages users of DPDK to slip versions, putting
> > > off
> > > reintegration to later, building up technical debt and causing
> > > their
> > > projects to miss support for new hardware or features.
> > > 3. It makes DPDK different to almost every other system library
> > > and
> > > framework that an operating systems might ship. This makes DPDK
> > > trickier
> > > to dynamically link against, package and maintain for OS
> > > maintainers.
> > >
> > > In order to address this issue, I have put together the minimal
> > > set of
> > > concrete proposals below for discussion at the Technical Board
> > > next
> > > Wednesday.
> > >
> > > I wanted to share this, as these might not yet be the right
> > > proposals,
> > > however I am putting them out there for feedback to start the
> > > discussion.
> > >
> > > Thanks,
> > >
> > > Ray K
> > >
> > >
> > > Experimental API
> > > 1. APIs designated as experimental are not considered part
> > > of the ABI
> > > and may change without warning at any time.
> > > 2. APIs designated as experimental must be marked
> > > depreciated for a
> > > least one quarterly release before removal.
> > > 3. APIs designated as experimental will no longer
> > > automatically graduate
> > > to core after one release, they may stay experimental until their
> > > author
> > > and the maintainer agree that graduation is appropriate.
> > >
> > > Core API (non-experimental API)
> > > 4. APIs designated as core must be depreciated for a least
> > > two years
> > > before removal, to facilitate the continued compatibility with
> > > LTS
> > > releases. A final removal notice will be published to the DPDK
> > > Mailing
> > > List, and if there are no strong objections only then an API may
> > > be
> > > removed.
> > > 5. APIs designated as core may be changed as follows:-
> > > 5.a The change proposer must demonstrated that the change
> > > has a
> > > supporting use case and could not be achieved in any other way.
> > > 5.b ABI version compatibility must be retained, as
> > > described below.
> >
> > Hi Ray,
> >
> > My somewhat rambly 2 cents :)
> >
> > While i think some solution has to be found for the situation, we
> > also have
> > to balance this against speed of development and new features
> > rollout.
> >
> > For example, let's consider what i am intimately familiar with -
> > the memory
> > rework. I have made enormous efforts to ensure that pre-18.05 and
> > post-18.05
> > remain as ABI/API compatible as possible, but there were a couple
> > of API
> > calls that were removed, and there couldn't have been any
> > replacements
> > (these API's were exposing internal structures that shouldn't have
> > been
> > exposed in the first place), and 18.05 also broke the ABI
> > compatibility,
> > because there was no way to do it without it (shared internal
> > structures
> > needed to change in part to support multiprocess).
> >
> > So, if i understand your proposal correctly, assuming a 2-year
> > waiting
> > period for the deprecation of core API's, you would essentially
> > still be
> > waiting for the memory rework to land for a year more. Moreover,
> > even
> > *after* it has landed, there was a continuous stream of
> > improvements and
> > bugfixes, some of which has broke ABI compatibility as well. Some
> > of them
> > were my fault (as in, i could've foreseen the need for those
> > changes, but
> > didn't), but others came as a result of people using these new
> > features in
> > the wild and reporting issues/problems/suggestions - i am but one
> > man, after
> > all. Plus, you know, there's only 24 hours in a day, and some stuff
> > takes
> > time to implement :)
> >
> > Since this rework goes right at the heart of DPDK (arguably there
> > isn't a
> > more "core" API than memory!), there is no (sane) way in the
> > universe to 1)
> > keep backwards compatibility for this, or 2) keep two parallel
> > versions of
> > it. We also need to test all that, and, to be honest, one
> > validation cycle
> > for a release wouldn't be enough to figure out all of the kinks and
> > implications of such a case. It was really great that memory rework
> > has
> > landed in 18.05 and we had time to improve and prepare it for an
> > 18.11 LTS -
> > i think everyone can say that it's in much better shape in 18.11
> > than it was
> > in 18.05, but if we couldn't do an ABI break here or there, this
> > rate of
> > improvements would have slowed down significantly.
> >
> > Now, i understand that this is probably a highly exceptional case,
> > but i'm
> > sure that maintainers of other parts of DPDK will have their own
> > examples of
> > similar things happening.
> >
> > I have no idea what a proper solution would look like. Any
> > "splitting" of
> > the trees into "experimental" vs. "stable" will end up causing the
> > same
> > issue - people choose to use stable over experimental because,
> > well, it's
> > more stable, and new/experimental features don't get tested as much
> > because
> > no one runs the thing in the first place.
> >
> > TL;DR we have to be careful not to constrain the pace of
> > development/bugfixing just for the sake of having a stable API/ABI
> > :)
> >
>
> Actually, I think we *do* need to constrain the pace of development
> for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project -
> it
> should just start acting like it.
>
> Now, in terms of features like the memory rework, that is indeed a
> case
> that there was no alternative other than a massive ABI break.
> However, for
> that rework there was a strong need for improvement in that area that
> we
> can make the case for an ABI break to support it - and it is of a
> scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are
> of
> that scale.
Fully agree.
It's normal for new project, big and small, to start without a
stability promise as development ramps up, and then steer toward
stability as the user base grows. Sometimes the switch is made explicit
by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
I don't think we crossed that boundary yet in this project, and I
believe that's the main question Ray was trying to raise: has the time
finally come for DPDK to do this phase shift?
Of course it comes with a price for all developers, and that's again
common.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should
> reduce
> the scope for ABI breaks.
Yes, I'm a big fan of accessors and opaque structs.
> 2. Once done, I think we should commit to having an ABI break only in
> the
> rarest of circumstances, and only with very large justification. I
> want us
> to get to the point where DPDK releases can immediately be picked up
> by all
> linux distros and rolled out because they are ABI compatible.
>
> I'm not sure I like the idea of planned ABI break releases - that
> strikes
> me as a plan where we end up with the same number of ABI breaks as
> before,
> just balled into one release.
I think that was intended as a compromise, especially as we move from
one model to the other, and more of a "if a breakage has to happen, it
must be in the X release" rather than "let's always break in the X
release" :-)
> Question for Kevin, Luca and others who look at distro-packaging: is
> it the
> case that each distro will only ship one version of DPDK, or is it
> possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
We can ship multiple versions, although it's more work so there should
be a good reason to do it. At the moment in Debian and Ubuntu we don't,
and we tend to ship whatever the latest LTS version is at the distro
freeze milestone - for example Debian 10 which will be released soon
(TM) will have 18.11.0.
> So, in short, I'm generally in favour of a zero-tolerance approach
> for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory
> layout or
> similar.
>
> Regards,
> /Bruce
>
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
@ 2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
` (2 subsequent siblings)
4 siblings, 2 replies; 200+ results
From: Luca Boccassi @ 2019-04-04 12:02 UTC (permalink / raw)
To: Bruce Richardson, Burakov, Anatoly
Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote:
> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> > On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > > Hi folks,
> > >
> > > Recently I started a discussion with the DPDK Technical Board on
> > > DPDK
> > > ABI/API stability. This was born out informal feedback I had
> > > received
> > > from a number of users of DPDK about ABI churn. In turn this
> > > feedback
> > > then prompted an ABI analysis of DPDK using tools from abi-
> > > laboratory.
> > >
> > > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> > >
> > >
> > > I guess the short story is that DPDK ABI hasn't really settled
> > > down as
> > > the project has matured. If you take a look at the “Backward
> > > Compat.”
> > > column which measures ABI compatibility compared to the previous
> > > releases, you will see significant churn in the ABI over
> > > successive
> > > releases since v16.04.
> > >
> > > Now compare DPDK to GStreamer as an example of a very mature
> > > project
> > > with a similar intent, a framework for building applications, and
> > > which
> > > enjoys a very stable API.
> > >
> > > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> > >
> > >
> > > The DPDK ABI churn has the following affects for users:-
> > >
> > > 1. The churn obliges users of DPDK to commit to a constant
> > > re-integration and re-validation effort for new versions of DPDK.
> > > This
> > > effort from their perspective may not add value to their
> > > consuming
> > > project, particular if they are only updating to "stay current".
> > > 2. The churn encourages users of DPDK to slip versions, putting
> > > off
> > > reintegration to later, building up technical debt and causing
> > > their
> > > projects to miss support for new hardware or features.
> > > 3. It makes DPDK different to almost every other system library
> > > and
> > > framework that an operating systems might ship. This makes DPDK
> > > trickier
> > > to dynamically link against, package and maintain for OS
> > > maintainers.
> > >
> > > In order to address this issue, I have put together the minimal
> > > set of
> > > concrete proposals below for discussion at the Technical Board
> > > next
> > > Wednesday.
> > >
> > > I wanted to share this, as these might not yet be the right
> > > proposals,
> > > however I am putting them out there for feedback to start the
> > > discussion.
> > >
> > > Thanks,
> > >
> > > Ray K
> > >
> > >
> > > Experimental API
> > > 1. APIs designated as experimental are not considered part
> > > of the ABI
> > > and may change without warning at any time.
> > > 2. APIs designated as experimental must be marked
> > > depreciated for a
> > > least one quarterly release before removal.
> > > 3. APIs designated as experimental will no longer
> > > automatically graduate
> > > to core after one release, they may stay experimental until their
> > > author
> > > and the maintainer agree that graduation is appropriate.
> > >
> > > Core API (non-experimental API)
> > > 4. APIs designated as core must be depreciated for a least
> > > two years
> > > before removal, to facilitate the continued compatibility with
> > > LTS
> > > releases. A final removal notice will be published to the DPDK
> > > Mailing
> > > List, and if there are no strong objections only then an API may
> > > be
> > > removed.
> > > 5. APIs designated as core may be changed as follows:-
> > > 5.a The change proposer must demonstrated that the change
> > > has a
> > > supporting use case and could not be achieved in any other way.
> > > 5.b ABI version compatibility must be retained, as
> > > described below.
> >
> > Hi Ray,
> >
> > My somewhat rambly 2 cents :)
> >
> > While i think some solution has to be found for the situation, we
> > also have
> > to balance this against speed of development and new features
> > rollout.
> >
> > For example, let's consider what i am intimately familiar with -
> > the memory
> > rework. I have made enormous efforts to ensure that pre-18.05 and
> > post-18.05
> > remain as ABI/API compatible as possible, but there were a couple
> > of API
> > calls that were removed, and there couldn't have been any
> > replacements
> > (these API's were exposing internal structures that shouldn't have
> > been
> > exposed in the first place), and 18.05 also broke the ABI
> > compatibility,
> > because there was no way to do it without it (shared internal
> > structures
> > needed to change in part to support multiprocess).
> >
> > So, if i understand your proposal correctly, assuming a 2-year
> > waiting
> > period for the deprecation of core API's, you would essentially
> > still be
> > waiting for the memory rework to land for a year more. Moreover,
> > even
> > *after* it has landed, there was a continuous stream of
> > improvements and
> > bugfixes, some of which has broke ABI compatibility as well. Some
> > of them
> > were my fault (as in, i could've foreseen the need for those
> > changes, but
> > didn't), but others came as a result of people using these new
> > features in
> > the wild and reporting issues/problems/suggestions - i am but one
> > man, after
> > all. Plus, you know, there's only 24 hours in a day, and some stuff
> > takes
> > time to implement :)
> >
> > Since this rework goes right at the heart of DPDK (arguably there
> > isn't a
> > more "core" API than memory!), there is no (sane) way in the
> > universe to 1)
> > keep backwards compatibility for this, or 2) keep two parallel
> > versions of
> > it. We also need to test all that, and, to be honest, one
> > validation cycle
> > for a release wouldn't be enough to figure out all of the kinks and
> > implications of such a case. It was really great that memory rework
> > has
> > landed in 18.05 and we had time to improve and prepare it for an
> > 18.11 LTS -
> > i think everyone can say that it's in much better shape in 18.11
> > than it was
> > in 18.05, but if we couldn't do an ABI break here or there, this
> > rate of
> > improvements would have slowed down significantly.
> >
> > Now, i understand that this is probably a highly exceptional case,
> > but i'm
> > sure that maintainers of other parts of DPDK will have their own
> > examples of
> > similar things happening.
> >
> > I have no idea what a proper solution would look like. Any
> > "splitting" of
> > the trees into "experimental" vs. "stable" will end up causing the
> > same
> > issue - people choose to use stable over experimental because,
> > well, it's
> > more stable, and new/experimental features don't get tested as much
> > because
> > no one runs the thing in the first place.
> >
> > TL;DR we have to be careful not to constrain the pace of
> > development/bugfixing just for the sake of having a stable API/ABI
> > :)
> >
>
> Actually, I think we *do* need to constrain the pace of development
> for the
> sake of ABI stability. At this stage DPDK has been around for quite a
> number of years and so should be considered a fairly mature project -
> it
> should just start acting like it.
>
> Now, in terms of features like the memory rework, that is indeed a
> case
> that there was no alternative other than a massive ABI break.
> However, for
> that rework there was a strong need for improvement in that area that
> we
> can make the case for an ABI break to support it - and it is of a
> scale
> that nothing other than an ABI change would do. For other areas and
> examples, I doubt there are many in the last couple of years that are
> of
> that scale.
Fully agree.
It's normal for new project, big and small, to start without a
stability promise as development ramps up, and then steer toward
stability as the user base grows. Sometimes the switch is made explicit
by crossing from a 0.x to a 1.x version numbering, sometimes it's not.
I don't think we crossed that boundary yet in this project, and I
believe that's the main question Ray was trying to raise: has the time
finally come for DPDK to do this phase shift?
Of course it comes with a price for all developers, and that's again
common.
> My thoughts on the matter are:
> 1. I think we really need to do work to start hiding more of our data
> structures - like what Stephen's latest RFC does. This hiding should
> reduce
> the scope for ABI breaks.
Yes, I'm a big fan of accessors and opaque structs.
> 2. Once done, I think we should commit to having an ABI break only in
> the
> rarest of circumstances, and only with very large justification. I
> want us
> to get to the point where DPDK releases can immediately be picked up
> by all
> linux distros and rolled out because they are ABI compatible.
>
> I'm not sure I like the idea of planned ABI break releases - that
> strikes
> me as a plan where we end up with the same number of ABI breaks as
> before,
> just balled into one release.
I think that was intended as a compromise, especially as we move from
one model to the other, and more of a "if a breakage has to happen, it
must be in the X release" rather than "let's always break in the X
release" :-)
> Question for Kevin, Luca and others who look at distro-packaging: is
> it the
> case that each distro will only ship one version of DPDK, or is it
> possible
> that if we have ABI breaks, a distro will provide two copies of DPDK
> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
We can ship multiple versions, although it's more work so there should
be a good reason to do it. At the moment in Debian and Ubuntu we don't,
and we tend to ship whatever the latest LTS version is at the distro
freeze milestone - for example Debian 10 which will be released soon
(TM) will have 18.11.0.
> So, in short, I'm generally in favour of a zero-tolerance approach
> for DPDK
> ABI breaks, and having ABI breaks as a major event reserved only for
> massive rework changes, such as major mbuf changes, or new memory
> layout or
> similar.
>
> Regards,
> /Bruce
>
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 10:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received
> > from a number of users of DPDK about ABI churn. In turn this feedback
> > then prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as
> > the project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant
> > re-integration and re-validation effort for new versions of DPDK. This
> > effort from their perspective may not add value to their consuming
> > project, particular if they are only updating to "stay current".
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their
> > projects to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS
> > releases. A final removal notice will be published to the DPDK Mailing
> > List, and if there are no strong objections only then an API may be
> > removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
>
> Hi Ray,
>
> My somewhat rambly 2 cents :)
>
> While i think some solution has to be found for the situation, we also have
> to balance this against speed of development and new features rollout.
>
> For example, let's consider what i am intimately familiar with - the memory
> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
> remain as ABI/API compatible as possible, but there were a couple of API
> calls that were removed, and there couldn't have been any replacements
> (these API's were exposing internal structures that shouldn't have been
> exposed in the first place), and 18.05 also broke the ABI compatibility,
> because there was no way to do it without it (shared internal structures
> needed to change in part to support multiprocess).
>
> So, if i understand your proposal correctly, assuming a 2-year waiting
> period for the deprecation of core API's, you would essentially still be
> waiting for the memory rework to land for a year more. Moreover, even
> *after* it has landed, there was a continuous stream of improvements and
> bugfixes, some of which has broke ABI compatibility as well. Some of them
> were my fault (as in, i could've foreseen the need for those changes, but
> didn't), but others came as a result of people using these new features in
> the wild and reporting issues/problems/suggestions - i am but one man, after
> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
> time to implement :)
>
> Since this rework goes right at the heart of DPDK (arguably there isn't a
> more "core" API than memory!), there is no (sane) way in the universe to 1)
> keep backwards compatibility for this, or 2) keep two parallel versions of
> it. We also need to test all that, and, to be honest, one validation cycle
> for a release wouldn't be enough to figure out all of the kinks and
> implications of such a case. It was really great that memory rework has
> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
> i think everyone can say that it's in much better shape in 18.11 than it was
> in 18.05, but if we couldn't do an ABI break here or there, this rate of
> improvements would have slowed down significantly.
>
> Now, i understand that this is probably a highly exceptional case, but i'm
> sure that maintainers of other parts of DPDK will have their own examples of
> similar things happening.
>
> I have no idea what a proper solution would look like. Any "splitting" of
> the trees into "experimental" vs. "stable" will end up causing the same
> issue - people choose to use stable over experimental because, well, it's
> more stable, and new/experimental features don't get tested as much because
> no one runs the thing in the first place.
>
> TL;DR we have to be careful not to constrain the pace of
> development/bugfixing just for the sake of having a stable API/ABI :)
>
Actually, I think we *do* need to constrain the pace of development for the
sake of ABI stability. At this stage DPDK has been around for quite a
number of years and so should be considered a fairly mature project - it
should just start acting like it.
Now, in terms of features like the memory rework, that is indeed a case
that there was no alternative other than a massive ABI break. However, for
that rework there was a strong need for improvement in that area that we
can make the case for an ABI break to support it - and it is of a scale
that nothing other than an ABI change would do. For other areas and
examples, I doubt there are many in the last couple of years that are of
that scale.
My thoughts on the matter are:
1. I think we really need to do work to start hiding more of our data
structures - like what Stephen's latest RFC does. This hiding should reduce
the scope for ABI breaks.
2. Once done, I think we should commit to having an ABI break only in the
rarest of circumstances, and only with very large justification. I want us
to get to the point where DPDK releases can immediately be picked up by all
linux distros and rolled out because they are ABI compatible.
I'm not sure I like the idea of planned ABI break releases - that strikes
me as a plan where we end up with the same number of ABI breaks as before,
just balled into one release.
Question for Kevin, Luca and others who look at distro-packaging: is it the
case that each distro will only ship one version of DPDK, or is it possible
that if we have ABI breaks, a distro will provide two copies of DPDK
simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
ABI breaks, and having ABI breaks as a major event reserved only for
massive rework changes, such as major mbuf changes, or new memory layout or
similar.
Regards,
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
` (4 more replies)
1 sibling, 5 replies; 200+ results
From: Bruce Richardson @ 2019-04-04 10:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Ray Kinsella, dev, Kevin Traynor, techboard
On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote:
> On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> > Hi folks,
> >
> > Recently I started a discussion with the DPDK Technical Board on DPDK
> > ABI/API stability. This was born out informal feedback I had received
> > from a number of users of DPDK about ABI churn. In turn this feedback
> > then prompted an ABI analysis of DPDK using tools from abi-laboratory.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
> >
> > I guess the short story is that DPDK ABI hasn't really settled down as
> > the project has matured. If you take a look at the “Backward Compat.”
> > column which measures ABI compatibility compared to the previous
> > releases, you will see significant churn in the ABI over successive
> > releases since v16.04.
> >
> > Now compare DPDK to GStreamer as an example of a very mature project
> > with a similar intent, a framework for building applications, and which
> > enjoys a very stable API.
> >
> > https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
> >
> > The DPDK ABI churn has the following affects for users:-
> >
> > 1. The churn obliges users of DPDK to commit to a constant
> > re-integration and re-validation effort for new versions of DPDK. This
> > effort from their perspective may not add value to their consuming
> > project, particular if they are only updating to "stay current".
> > 2. The churn encourages users of DPDK to slip versions, putting off
> > reintegration to later, building up technical debt and causing their
> > projects to miss support for new hardware or features.
> > 3. It makes DPDK different to almost every other system library and
> > framework that an operating systems might ship. This makes DPDK trickier
> > to dynamically link against, package and maintain for OS maintainers.
> >
> > In order to address this issue, I have put together the minimal set of
> > concrete proposals below for discussion at the Technical Board next
> > Wednesday.
> >
> > I wanted to share this, as these might not yet be the right proposals,
> > however I am putting them out there for feedback to start the discussion.
> >
> > Thanks,
> >
> > Ray K
> >
> >
> > Experimental API
> > 1. APIs designated as experimental are not considered part of the ABI
> > and may change without warning at any time.
> > 2. APIs designated as experimental must be marked depreciated for a
> > least one quarterly release before removal.
> > 3. APIs designated as experimental will no longer automatically graduate
> > to core after one release, they may stay experimental until their author
> > and the maintainer agree that graduation is appropriate.
> >
> > Core API (non-experimental API)
> > 4. APIs designated as core must be depreciated for a least two years
> > before removal, to facilitate the continued compatibility with LTS
> > releases. A final removal notice will be published to the DPDK Mailing
> > List, and if there are no strong objections only then an API may be
> > removed.
> > 5. APIs designated as core may be changed as follows:-
> > 5.a The change proposer must demonstrated that the change has a
> > supporting use case and could not be achieved in any other way.
> > 5.b ABI version compatibility must be retained, as described below.
>
> Hi Ray,
>
> My somewhat rambly 2 cents :)
>
> While i think some solution has to be found for the situation, we also have
> to balance this against speed of development and new features rollout.
>
> For example, let's consider what i am intimately familiar with - the memory
> rework. I have made enormous efforts to ensure that pre-18.05 and post-18.05
> remain as ABI/API compatible as possible, but there were a couple of API
> calls that were removed, and there couldn't have been any replacements
> (these API's were exposing internal structures that shouldn't have been
> exposed in the first place), and 18.05 also broke the ABI compatibility,
> because there was no way to do it without it (shared internal structures
> needed to change in part to support multiprocess).
>
> So, if i understand your proposal correctly, assuming a 2-year waiting
> period for the deprecation of core API's, you would essentially still be
> waiting for the memory rework to land for a year more. Moreover, even
> *after* it has landed, there was a continuous stream of improvements and
> bugfixes, some of which has broke ABI compatibility as well. Some of them
> were my fault (as in, i could've foreseen the need for those changes, but
> didn't), but others came as a result of people using these new features in
> the wild and reporting issues/problems/suggestions - i am but one man, after
> all. Plus, you know, there's only 24 hours in a day, and some stuff takes
> time to implement :)
>
> Since this rework goes right at the heart of DPDK (arguably there isn't a
> more "core" API than memory!), there is no (sane) way in the universe to 1)
> keep backwards compatibility for this, or 2) keep two parallel versions of
> it. We also need to test all that, and, to be honest, one validation cycle
> for a release wouldn't be enough to figure out all of the kinks and
> implications of such a case. It was really great that memory rework has
> landed in 18.05 and we had time to improve and prepare it for an 18.11 LTS -
> i think everyone can say that it's in much better shape in 18.11 than it was
> in 18.05, but if we couldn't do an ABI break here or there, this rate of
> improvements would have slowed down significantly.
>
> Now, i understand that this is probably a highly exceptional case, but i'm
> sure that maintainers of other parts of DPDK will have their own examples of
> similar things happening.
>
> I have no idea what a proper solution would look like. Any "splitting" of
> the trees into "experimental" vs. "stable" will end up causing the same
> issue - people choose to use stable over experimental because, well, it's
> more stable, and new/experimental features don't get tested as much because
> no one runs the thing in the first place.
>
> TL;DR we have to be careful not to constrain the pace of
> development/bugfixing just for the sake of having a stable API/ABI :)
>
Actually, I think we *do* need to constrain the pace of development for the
sake of ABI stability. At this stage DPDK has been around for quite a
number of years and so should be considered a fairly mature project - it
should just start acting like it.
Now, in terms of features like the memory rework, that is indeed a case
that there was no alternative other than a massive ABI break. However, for
that rework there was a strong need for improvement in that area that we
can make the case for an ABI break to support it - and it is of a scale
that nothing other than an ABI change would do. For other areas and
examples, I doubt there are many in the last couple of years that are of
that scale.
My thoughts on the matter are:
1. I think we really need to do work to start hiding more of our data
structures - like what Stephen's latest RFC does. This hiding should reduce
the scope for ABI breaks.
2. Once done, I think we should commit to having an ABI break only in the
rarest of circumstances, and only with very large justification. I want us
to get to the point where DPDK releases can immediately be picked up by all
linux distros and rolled out because they are ABI compatible.
I'm not sure I like the idea of planned ABI break releases - that strikes
me as a plan where we end up with the same number of ABI breaks as before,
just balled into one release.
Question for Kevin, Luca and others who look at distro-packaging: is it the
case that each distro will only ship one version of DPDK, or is it possible
that if we have ABI breaks, a distro will provide two copies of DPDK
simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version?
So, in short, I'm generally in favour of a zero-tolerance approach for DPDK
ABI breaks, and having ABI breaks as a major event reserved only for
massive rework changes, such as major mbuf changes, or new memory layout or
similar.
Regards,
/Bruce
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
@ 2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 9:47 UTC (permalink / raw)
To: Ray Kinsella, dev, techboard
On 03/04/2019 16:42, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
> I guess the short story is that DPDK ABI hasn't really settled down as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK. This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
+1
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
I don't think they automatically graduate in the current scheme, so it
would seem to be no change to the process.
One thing to note is that in the current experimental API scheme those
API are tagged as deprecated which can cause problems with application
build/CI if they are used. But this is more related to implementation
rather than the classification indicating the API may change. It might
need to change if there was a trend for keeping API as experimental for
a longer time.
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
I agree with the sentiment but it needs real buy in from authors.
Otherwise the burden falls on the reviewer to spend time
exploring/finding a way not to change the API.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-10 5:14 9% ` Honnappa Nagarahalli
3 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2019-04-04 9:47 UTC (permalink / raw)
To: Ray Kinsella, dev, techboard
On 03/04/2019 16:42, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
> I guess the short story is that DPDK ABI hasn't really settled down as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK. This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
+1
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
I don't think they automatically graduate in the current scheme, so it
would seem to be no change to the process.
One thing to note is that in the current experimental API scheme those
API are tagged as deprecated which can cause problems with application
build/CI if they are used. But this is more related to implementation
rather than the classification indicating the API may change. It might
need to change if there was a trend for keeping API as experimental for
a longer time.
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
I agree with the sentiment but it needs real buy in from authors.
Otherwise the burden falls on the reviewer to spend time
exploring/finding a way not to change the API.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-04 9:29 9% ` Burakov, Anatoly
@ 2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 9:29 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard
On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
> I guess the short story is that DPDK ABI hasn't really settled down as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK. This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
Hi Ray,
My somewhat rambly 2 cents :)
While i think some solution has to be found for the situation, we also
have to balance this against speed of development and new features rollout.
For example, let's consider what i am intimately familiar with - the
memory rework. I have made enormous efforts to ensure that pre-18.05 and
post-18.05 remain as ABI/API compatible as possible, but there were a
couple of API calls that were removed, and there couldn't have been any
replacements (these API's were exposing internal structures that
shouldn't have been exposed in the first place), and 18.05 also broke
the ABI compatibility, because there was no way to do it without it
(shared internal structures needed to change in part to support
multiprocess).
So, if i understand your proposal correctly, assuming a 2-year waiting
period for the deprecation of core API's, you would essentially still be
waiting for the memory rework to land for a year more. Moreover, even
*after* it has landed, there was a continuous stream of improvements and
bugfixes, some of which has broke ABI compatibility as well. Some of
them were my fault (as in, i could've foreseen the need for those
changes, but didn't), but others came as a result of people using these
new features in the wild and reporting issues/problems/suggestions - i
am but one man, after all. Plus, you know, there's only 24 hours in a
day, and some stuff takes time to implement :)
Since this rework goes right at the heart of DPDK (arguably there isn't
a more "core" API than memory!), there is no (sane) way in the universe
to 1) keep backwards compatibility for this, or 2) keep two parallel
versions of it. We also need to test all that, and, to be honest, one
validation cycle for a release wouldn't be enough to figure out all of
the kinks and implications of such a case. It was really great that
memory rework has landed in 18.05 and we had time to improve and prepare
it for an 18.11 LTS - i think everyone can say that it's in much better
shape in 18.11 than it was in 18.05, but if we couldn't do an ABI break
here or there, this rate of improvements would have slowed down
significantly.
Now, i understand that this is probably a highly exceptional case, but
i'm sure that maintainers of other parts of DPDK will have their own
examples of similar things happening.
I have no idea what a proper solution would look like. Any "splitting"
of the trees into "experimental" vs. "stable" will end up causing the
same issue - people choose to use stable over experimental because,
well, it's more stable, and new/experimental features don't get tested
as much because no one runs the thing in the first place.
TL;DR we have to be careful not to constrain the pace of
development/bugfixing just for the sake of having a stable API/ABI :)
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 19:53 9% ` Luca Boccassi
@ 2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-10 5:14 9% ` Honnappa Nagarahalli
3 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-04 9:29 UTC (permalink / raw)
To: Ray Kinsella, dev, Kevin Traynor, techboard
On 03-Apr-19 4:42 PM, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
> I guess the short story is that DPDK ABI hasn't really settled down as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK. This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right proposals,
> however I am putting them out there for feedback to start the discussion.
>
> Thanks,
>
> Ray K
>
>
> Experimental API
> 1. APIs designated as experimental are not considered part of the ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically graduate
> to core after one release, they may stay experimental until their author
> and the maintainer agree that graduation is appropriate.
>
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
Hi Ray,
My somewhat rambly 2 cents :)
While i think some solution has to be found for the situation, we also
have to balance this against speed of development and new features rollout.
For example, let's consider what i am intimately familiar with - the
memory rework. I have made enormous efforts to ensure that pre-18.05 and
post-18.05 remain as ABI/API compatible as possible, but there were a
couple of API calls that were removed, and there couldn't have been any
replacements (these API's were exposing internal structures that
shouldn't have been exposed in the first place), and 18.05 also broke
the ABI compatibility, because there was no way to do it without it
(shared internal structures needed to change in part to support
multiprocess).
So, if i understand your proposal correctly, assuming a 2-year waiting
period for the deprecation of core API's, you would essentially still be
waiting for the memory rework to land for a year more. Moreover, even
*after* it has landed, there was a continuous stream of improvements and
bugfixes, some of which has broke ABI compatibility as well. Some of
them were my fault (as in, i could've foreseen the need for those
changes, but didn't), but others came as a result of people using these
new features in the wild and reporting issues/problems/suggestions - i
am but one man, after all. Plus, you know, there's only 24 hours in a
day, and some stuff takes time to implement :)
Since this rework goes right at the heart of DPDK (arguably there isn't
a more "core" API than memory!), there is no (sane) way in the universe
to 1) keep backwards compatibility for this, or 2) keep two parallel
versions of it. We also need to test all that, and, to be honest, one
validation cycle for a release wouldn't be enough to figure out all of
the kinks and implications of such a case. It was really great that
memory rework has landed in 18.05 and we had time to improve and prepare
it for an 18.11 LTS - i think everyone can say that it's in much better
shape in 18.11 than it was in 18.05, but if we couldn't do an ABI break
here or there, this rate of improvements would have slowed down
significantly.
Now, i understand that this is probably a highly exceptional case, but
i'm sure that maintainers of other parts of DPDK will have their own
examples of similar things happening.
I have no idea what a proper solution would look like. Any "splitting"
of the trees into "experimental" vs. "stable" will end up causing the
same issue - people choose to use stable over experimental because,
well, it's more stable, and new/experimental features don't get tested
as much because no one runs the thing in the first place.
TL;DR we have to be careful not to constrain the pace of
development/bugfixing just for the sake of having a stable API/ABI :)
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by default, to
> accommodate greater use of ABI versioning by DPDK consumers.
>
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
@ 2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-04 8:51 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v11:
- fix the meson build issue
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 15 +
drivers/net/af_xdp/meson.build | 19 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1104 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v11 0/1] Introduce AF_XDP PMD
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
@ 2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Xiaolong Ye @ 2019-04-04 8:51 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v11:
- fix the meson build issue
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 15 +
drivers/net/af_xdp/meson.build | 19 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1104 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] DPDK ABI/API Stability
2019-04-03 19:53 9% ` Luca Boccassi
@ 2019-04-03 19:53 9% ` Luca Boccassi
0 siblings, 0 replies; 200+ results
From: Luca Boccassi @ 2019-04-03 19:53 UTC (permalink / raw)
To: Ray Kinsella, dev; +Cc: Christian Ehrhardt, Kevin Traynor, techboard
On Wed, 2019-04-03 at 16:42 +0100, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-
> laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
>
> I guess the short story is that DPDK ABI hasn't really settled down
> as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and
> which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK.
> This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK
> trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set
> of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right
> proposals,
> however I am putting them out there for feedback to start the
> discussion.
>
> Thanks,
>
> Ray K
Hello Ray,
It will not come as a surprise to anybody when I say I fully agree with
your analysis :-)
One of the consequences is that this has a tendency to lead to
vendorization - given distros have to move on, and moving on with
application is a lot of work as you pointed out, the easiest solution
is to fork and embed.
If we can't change this, I think at the very least we should be more
explicit in the documentation about how the API is in flux. At least
project managers would be able to know up front that there is a higher-
than-normal long-term opex attached to a DPDK application, even when
all other development stops.
A couple of comments inline below.
> Experimental API
> 1. APIs designated as experimental are not considered part of the
> ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for
> a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their
> author
> and the maintainer agree that graduation is appropriate.
From my experience in other projects, if a symbol is available in a
shared library, it will be used. So one thing that's missing from the
current system, which is already good and very helpful, is being able
to completely disable the experimental APIs.
In the past I looked into stopping to export those symbols but the
issue is intra-project dependencies - this can only be done if, for
example, PMDs are not allowed to use an experimental RTE api, unless
it's wrapped in an experimental ifdef (or similar mechanism). This of
course would be a major pain for everybody involved.
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two
> years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK
> Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by
> default, to
> accommodate greater use of ABI versioning by DPDK consumers.
The switch to Meson will help here, as it's the default.
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with
> the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the
> previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK
> 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
There is also an additional problem with the way we do ABI versioning,
we talked about it many times - ABI bumps need to be "sticky" and
propagate. Eg: if libfoo goes from 1 to 2, all libraries linking to foo
also need a bump. We don't do this, which made necessary the
introduction of the "major abi revision" option, which essentially
makes all the ABI versions match the release version, and which we use
in Debian/Ubuntu.
IMHO we should do a mix of the two - move to always use major version,
but of the LTS as you suggest. So all ABI revisions will be 19.11 until
20.11 is out, and so on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] DPDK ABI/API Stability
@ 2019-04-03 19:53 9% ` Luca Boccassi
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-04 9:29 9% ` Burakov, Anatoly
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: Luca Boccassi @ 2019-04-03 19:53 UTC (permalink / raw)
To: Ray Kinsella, dev; +Cc: Christian Ehrhardt, Kevin Traynor, techboard
On Wed, 2019-04-03 at 16:42 +0100, Ray Kinsella wrote:
> Hi folks,
>
> Recently I started a discussion with the DPDK Technical Board on DPDK
> ABI/API stability. This was born out informal feedback I had received
> from a number of users of DPDK about ABI churn. In turn this feedback
> then prompted an ABI analysis of DPDK using tools from abi-
> laboratory.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
>
>
> I guess the short story is that DPDK ABI hasn't really settled down
> as
> the project has matured. If you take a look at the “Backward Compat.”
> column which measures ABI compatibility compared to the previous
> releases, you will see significant churn in the ABI over successive
> releases since v16.04.
>
> Now compare DPDK to GStreamer as an example of a very mature project
> with a similar intent, a framework for building applications, and
> which
> enjoys a very stable API.
>
> https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer
>
>
> The DPDK ABI churn has the following affects for users:-
>
> 1. The churn obliges users of DPDK to commit to a constant
> re-integration and re-validation effort for new versions of DPDK.
> This
> effort from their perspective may not add value to their consuming
> project, particular if they are only updating to "stay current".
> 2. The churn encourages users of DPDK to slip versions, putting off
> reintegration to later, building up technical debt and causing their
> projects to miss support for new hardware or features.
> 3. It makes DPDK different to almost every other system library and
> framework that an operating systems might ship. This makes DPDK
> trickier
> to dynamically link against, package and maintain for OS maintainers.
>
> In order to address this issue, I have put together the minimal set
> of
> concrete proposals below for discussion at the Technical Board next
> Wednesday.
>
> I wanted to share this, as these might not yet be the right
> proposals,
> however I am putting them out there for feedback to start the
> discussion.
>
> Thanks,
>
> Ray K
Hello Ray,
It will not come as a surprise to anybody when I say I fully agree with
your analysis :-)
One of the consequences is that this has a tendency to lead to
vendorization - given distros have to move on, and moving on with
application is a lot of work as you pointed out, the easiest solution
is to fork and embed.
If we can't change this, I think at the very least we should be more
explicit in the documentation about how the API is in flux. At least
project managers would be able to know up front that there is a higher-
than-normal long-term opex attached to a DPDK application, even when
all other development stops.
A couple of comments inline below.
> Experimental API
> 1. APIs designated as experimental are not considered part of the
> ABI
> and may change without warning at any time.
> 2. APIs designated as experimental must be marked depreciated for
> a
> least one quarterly release before removal.
> 3. APIs designated as experimental will no longer automatically
> graduate
> to core after one release, they may stay experimental until their
> author
> and the maintainer agree that graduation is appropriate.
>From my experience in other projects, if a symbol is available in a
shared library, it will be used. So one thing that's missing from the
current system, which is already good and very helpful, is being able
to completely disable the experimental APIs.
In the past I looked into stopping to export those symbols but the
issue is intra-project dependencies - this can only be done if, for
example, PMDs are not allowed to use an experimental RTE api, unless
it's wrapped in an experimental ifdef (or similar mechanism). This of
course would be a major pain for everybody involved.
> Core API (non-experimental API)
> 4. APIs designated as core must be depreciated for a least two
> years
> before removal, to facilitate the continued compatibility with LTS
> releases. A final removal notice will be published to the DPDK
> Mailing
> List, and if there are no strong objections only then an API may be
> removed.
> 5. APIs designated as core may be changed as follows:-
> 5.a The change proposer must demonstrated that the change has a
> supporting use case and could not be achieved in any other way.
> 5.b ABI version compatibility must be retained, as described below.
>
> Shared Libraries
> 6. DPDK will move to shared libraries & dynamic linking by
> default, to
> accommodate greater use of ABI versioning by DPDK consumers.
The switch to Meson will help here, as it's the default.
> ABI Versioning
> 7. New quarterly releases of DPDK will remain ABI compatible with
> the
> most recent DPDK LTS release.
> (e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
> 8. New DPDK LTS releases will remain ABI compatible with the
> previous
> two DPDK LTS releases.
> (e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK
> 18.11,
> DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
> 8. & 9. will be achieved with ABI symbol versioning.
There is also an additional problem with the way we do ABI versioning,
we talked about it many times - ABI bumps need to be "sticky" and
propagate. Eg: if libfoo goes from 1 to 2, all libraries linking to foo
also need a bump. We don't do this, which made necessary the
introduction of the "major abi revision" option, which essentially
makes all the ABI versions match the release version, and which we use
in Debian/Ubuntu.
IMHO we should do a mix of the two - move to always use major version,
but of the LTS as you suggest. So all ABI revisions will be 19.11 until
20.11 is out, and so on.
--
Kind regards,
Luca Boccassi
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [RFC 5/5] eal: make lcore_config private
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
@ 2019-04-03 17:16 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7477ed2d9550..0b157b3e07ce 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..291e56dabc91 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-03 17:16 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 46 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 +++++++++++++++++------
3 files changed, 96 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index bdad1ddbeedf..995fbf177b93 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -188,6 +188,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..806204d9f73d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,52 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+enum rte_lcore_state_t
+rte_lcore_state(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].state;
+}
+
+int
+rte_lcore_return_code(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7477ed2d9550 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,7 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +169,37 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned rte_lcore_to_socket_id(unsigned lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t rte_lcore_cpuset(unsigned lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned lcore_id);
/**
* Test if an lcore is enabled.
@@ -201,6 +219,17 @@ rte_lcore_is_enabled(unsigned lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
+/**
+ * Get the state of an lcore ID.
+ *
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * the current state of that lcore
+ */
+enum rte_lcore_state_t __rte_experimental
+rte_lcore_state(unsigned lcore_id);
+
/**
* Get the next enabled lcore ID.
*
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [RFC 5/5] eal: make lcore_config private
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-04-03 17:16 3% ` Stephen Hemminger
2019-04-03 17:16 3% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The internal structure of lcore_config should not be part of
visible API/ABI. Make it private to EAL.
Rearrange and resize the fields in the structure so it takes
less memory (and cache footprint).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/librte_eal/common/eal_common_launch.c | 2 ++
lib/librte_eal/common/eal_private.h | 22 +++++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 24 -----------------------
lib/librte_eal/common/rte_service.c | 2 ++
lib/librte_eal/rte_eal_version.map | 1 -
5 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_launch.c b/lib/librte_eal/common/eal_common_launch.c
index fe0ba3f0d617..cf52d717f68e 100644
--- a/lib/librte_eal/common/eal_common_launch.c
+++ b/lib/librte_eal/common/eal_common_launch.c
@@ -15,6 +15,8 @@
#include <rte_per_lcore.h>
#include <rte_lcore.h>
+#include "eal_private.h"
+
/*
* Wait until a lcore finished its job.
*/
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 798ede553b21..25e80547904f 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -10,6 +10,28 @@
#include <stdio.h>
#include <rte_dev.h>
+#include <rte_lcore.h>
+
+/**
+ * Structure storing internal configuration (per-lcore)
+ */
+struct lcore_config {
+ uint32_t core_id; /**< core number on socket for this lcore */
+ uint32_t core_index; /**< relative index, starting from 0 */
+ uint16_t socket_id; /**< physical socket id for this lcore */
+ uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
+ uint8_t detected; /**< true if lcore was detected */
+ volatile enum rte_lcore_state_t state; /**< lcore state */
+ rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
+ pthread_t thread_id; /**< pthread identifier */
+ int pipe_master2slave[2]; /**< communication pipe with master */
+ int pipe_slave2master[2]; /**< communication pipe with master */
+ lcore_function_t * volatile f; /**< function to call */
+ void * volatile arg; /**< argument of function */
+ volatile int ret; /**< return value of function */
+};
+
+extern struct lcore_config lcore_config[RTE_MAX_LCORE];
/**
* Initialize the memzone subsystem (private to eal).
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index 7477ed2d9550..0b157b3e07ce 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -37,30 +37,6 @@ typedef cpuset_t rte_cpuset_t;
} while (0)
#endif
-/**
- * Structure storing internal configuration (per-lcore)
- */
-struct lcore_config {
- unsigned detected; /**< true if lcore was detected */
- pthread_t thread_id; /**< pthread identifier */
- int pipe_master2slave[2]; /**< communication pipe with master */
- int pipe_slave2master[2]; /**< communication pipe with master */
- lcore_function_t * volatile f; /**< function to call */
- void * volatile arg; /**< argument of function */
- volatile int ret; /**< return value of function */
- volatile enum rte_lcore_state_t state; /**< lcore state */
- unsigned socket_id; /**< physical socket id for this lcore */
- unsigned core_id; /**< core number on socket for this lcore */
- int core_index; /**< relative index, starting from 0 */
- rte_cpuset_t cpuset; /**< cpu set which the lcore affinity to */
- uint8_t core_role; /**< role of core eg: OFF, RTE, SERVICE */
-};
-
-/**
- * Internal configuration (per-lcore)
- */
-extern struct lcore_config lcore_config[RTE_MAX_LCORE];
-
RTE_DECLARE_PER_LCORE(unsigned, _lcore_id); /**< Per thread "lcore id". */
RTE_DECLARE_PER_LCORE(rte_cpuset_t, _cpuset); /**< Per thread "cpuset". */
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 5f75e5a53fbf..8d53d966446a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -21,6 +21,8 @@
#include <rte_memory.h>
#include <rte_malloc.h>
+#include "eal_private.h"
+
#define RTE_SERVICE_NUM_MAX 64
#define SERVICE_F_REGISTERED (1 << 0)
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index d6e375135ad1..291e56dabc91 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -4,7 +4,6 @@ DPDK_2.0 {
__rte_panic;
eal_parse_sysfs_value;
eal_timer_source;
- lcore_config;
per_lcore__lcore_id;
per_lcore__rte_errno;
rte_calloc;
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config
@ 2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-03 17:16 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The fields of the internal EAL core configuration are currently
laid bare as part of the API. This is not good practice and limits
fixing issues with layout and sizes.
Make new accessor functions for the fields used by current drivers
and examples. Mark the state and return code functions as experimental
since these values might change in the future and probably shouldn't
have been used by non EAL code anyway.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++
lib/librte_eal/common/eal_common_lcore.c | 46 ++++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 +++++++++++++++++------
3 files changed, 96 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index bdad1ddbeedf..995fbf177b93 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -188,6 +188,13 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* eal: the lcore config structure ``struct lcore_config`` will be made
+ internal to the EAL in a future release. This will allow the structure to
+ change without impacting API or ABI. All accesses to fields of this
+ structure should be done by the corresponding accessor functions.
+ For example, instead of using ``lcore_config[lcore_id].socket_id``
+ the function ``rte_lcore_socket_id(lcore_id)`` should be used instead.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/eal_common_lcore.c b/lib/librte_eal/common/eal_common_lcore.c
index 1cbac42286ba..806204d9f73d 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -16,6 +16,52 @@
#include "eal_private.h"
#include "eal_thread.h"
+int rte_lcore_index(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_index;
+}
+
+int rte_lcore_to_cpu_id(int lcore_id)
+{
+ if (unlikely(lcore_id >= RTE_MAX_LCORE))
+ return -1;
+
+ if (lcore_id < 0)
+ lcore_id = (int)rte_lcore_id();
+
+ return lcore_config[lcore_id].core_id;
+}
+
+rte_cpuset_t rte_lcore_cpuset(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].cpuset;
+}
+
+unsigned
+rte_lcore_to_socket_id(unsigned int lcore_id)
+{
+ return lcore_config[lcore_id].socket_id;
+}
+
+enum rte_lcore_state_t
+rte_lcore_state(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].state;
+}
+
+int
+rte_lcore_return_code(unsigned lcore_id)
+{
+ return lcore_config[lcore_id].ret;
+}
+
+
static int
socket_id_cmp(const void *a, const void *b)
{
diff --git a/lib/librte_eal/common/include/rte_lcore.h b/lib/librte_eal/common/include/rte_lcore.h
index dea17f500065..7477ed2d9550 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -121,15 +121,7 @@ rte_lcore_count(void)
* @return
* The relative index, or -1 if not enabled.
*/
-static inline int
-rte_lcore_index(int lcore_id)
-{
- if (lcore_id >= RTE_MAX_LCORE)
- return -1;
- if (lcore_id < 0)
- lcore_id = (int)rte_lcore_id();
- return lcore_config[lcore_id].core_index;
-}
+int rte_lcore_index(int lcore_id);
/**
* Return the ID of the physical socket of the logical core we are
@@ -177,11 +169,37 @@ rte_socket_id_by_idx(unsigned int idx);
* @return
* the ID of lcoreid's physical socket
*/
-static inline unsigned
-rte_lcore_to_socket_id(unsigned lcore_id)
-{
- return lcore_config[lcore_id].socket_id;
-}
+unsigned rte_lcore_to_socket_id(unsigned lcore_id);
+
+/**
+ * Return the id of the lcore on a socket starting from zero.
+ *
+ * @param lcore_id
+ * The targeted lcore, or -1 for the current one.
+ * @return
+ * The relative index, or -1 if not enabled.
+ */
+int rte_lcore_to_cpu_id(int lcore_id);
+
+/**
+ * Return the cpuset for a given lcore.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * The cpuset of that lcore
+ */
+rte_cpuset_t rte_lcore_cpuset(unsigned lcore_id);
+
+/**
+ * Get the return code from a lcore thread.
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1
+ * and finished
+ * @return
+ * the return code from the lcore thread
+ */
+int __rte_experimental
+rte_lcore_return_code(unsigned lcore_id);
/**
* Test if an lcore is enabled.
@@ -201,6 +219,17 @@ rte_lcore_is_enabled(unsigned lcore_id)
return cfg->lcore_role[lcore_id] == ROLE_RTE;
}
+/**
+ * Get the state of an lcore ID.
+ *
+ * @param lcore_id
+ * the targeted lcore, which MUST be between 0 and RTE_MAX_LCORE-1.
+ * @return
+ * the current state of that lcore
+ */
+enum rte_lcore_state_t __rte_experimental
+rte_lcore_state(unsigned lcore_id);
+
/**
* Get the next enabled lcore ID.
*
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v10 0/1] Introduce AF_XDP PMD
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
@ 2019-04-03 16:59 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-03 16:59 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 14 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1105 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v10 0/1] Introduce AF_XDP PMD
@ 2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
1 sibling, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-04-03 16:59 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit, Luca Boccassi
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Bruce Richardson, Ananyev Konstantin, David Marchand,
Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v10:
- refine the Makefile, remove RTE_KERNELDIR related CFLAGS
- add a new internal file af_xdp_deps.h to handle the dependency for
asm/barrier.h
- fix a typo observed by Stephen
- rename xsk.h to bpf/xsk.h as xsk.h is assumed to be installed in
/usr/local/include/bpf
- add libbpf build steps in af_xdp.rst
v9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build & install libbpf in tools/lib/bpf
cd tools/lib/bpf
make install_lib
make install_headers
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 50 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 28 +
drivers/net/af_xdp/af_xdp_deps.h | 14 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 955 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
14 files changed, 1105 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/af_xdp_deps.h
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
Results 8401-8600 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2018-10-24 8:18 [dpdk-dev] [RFC 00/14] prefix network structures Olivier Matz
2019-04-10 8:32 1% ` [dpdk-dev] [RFC v2 " Olivier Matz
2019-04-10 8:32 1% ` Olivier Matz
2018-11-22 3:30 [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library Honnappa Nagarahalli
2019-04-12 20:20 ` [dpdk-dev] [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-12 20:20 ` [dpdk-dev] [PATCH v5 1/3] rcu: " Honnappa Nagarahalli
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:06 3% ` Stephen Hemminger
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 22:24 3% ` Honnappa Nagarahalli
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-12 23:06 0% ` Stephen Hemminger
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 12:24 0% ` Ananyev, Konstantin
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 15:38 0% ` Stephen Hemminger
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 17:39 0% ` Ananyev, Konstantin
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 18:56 0% ` Honnappa Nagarahalli
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-15 21:26 3% ` Stephen Hemminger
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 5:29 4% ` Honnappa Nagarahalli
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 14:54 0% ` Stephen Hemminger
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 16:56 4% ` Honnappa Nagarahalli
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-16 21:22 3% ` Stephen Hemminger
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 1:45 0% ` Honnappa Nagarahalli
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 13:39 3% ` Ananyev, Konstantin
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:02 0% ` Honnappa Nagarahalli
2019-04-17 14:18 0% ` Thomas Monjalon
2019-04-17 14:18 0% ` Thomas Monjalon
2019-03-01 8:09 [dpdk-dev] [PATCH v1 0/6] Introduce AF_XDP PMD Xiaolong Ye
2019-04-03 16:59 2% ` [dpdk-dev] [PATCH v10 0/1] " Xiaolong Ye
2019-04-03 16:59 2% ` Xiaolong Ye
2019-04-04 8:51 2% ` [dpdk-dev] [PATCH v11 " Xiaolong Ye
2019-04-04 8:51 2% ` Xiaolong Ye
2019-04-04 16:13 0% ` Ferruh Yigit
2019-04-04 16:13 0% ` Ferruh Yigit
2019-03-04 11:18 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-11 17:22 ` Ferruh Yigit
2019-04-12 15:07 ` Thomas Monjalon
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:38 3% ` Ferruh Yigit
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:45 0% ` Thomas Monjalon
2019-04-12 15:57 0% ` Ferruh Yigit
2019-04-12 15:57 0% ` Ferruh Yigit
2019-03-06 15:03 [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-18 21:35 ` [dpdk-dev] [PATCH v7 " Gage Eads
2019-03-18 21:49 ` Eads, Gage
2019-03-19 15:51 ` Stephen Hemminger
2019-04-01 19:23 ` Eads, Gage
2019-04-02 10:16 ` Ola Liljedahl
2019-04-04 22:28 0% ` Eads, Gage
2019-04-04 22:28 0% ` Eads, Gage
2019-03-06 17:20 [dpdk-dev] [PATCH v4 0/2] Timer library changes Erik Gabriel Carrillo
2019-04-15 21:41 5% ` [dpdk-dev] [PATCH v5 " Erik Gabriel Carrillo
2019-04-15 21:41 5% ` Erik Gabriel Carrillo
2019-03-14 15:12 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-19 17:18 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API Ferruh Yigit
2019-03-26 9:29 ` David Marchand
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 13:29 0% ` Thomas Monjalon
2019-04-12 14:32 0% ` David Marchand
2019-04-12 14:32 0% ` David Marchand
2019-04-12 16:05 0% ` Stephen Hemminger
2019-04-12 16:05 0% ` Stephen Hemminger
2019-03-18 11:56 [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
2019-04-05 14:35 4% ` [dpdk-dev] [PATCH] " Hajkowski
2019-04-05 14:35 4% ` Hajkowski
2019-03-19 14:05 [dpdk-dev] [PATCH] doc: fix abi check script examples David Marchand
2019-03-19 17:19 ` Neil Horman
2019-04-05 8:30 4% ` Thomas Monjalon
2019-04-05 8:30 4% ` Thomas Monjalon
2019-04-03 15:42 [dpdk-dev] DPDK ABI/API Stability Ray Kinsella
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-03 19:53 9% ` Luca Boccassi
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 9:29 9% ` Burakov, Anatoly
2019-04-04 10:54 9% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54 9% ` Bruce Richardson
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 12:02 4% ` Luca Boccassi
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:05 7% ` Ray Kinsella
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-04 13:10 8% ` Bruce Richardson
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-05 13:25 4% ` Ray Kinsella
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-07 9:37 4% ` Thomas Monjalon
2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 13:21 4% ` Luca Boccassi
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 12:52 7% ` Ray Kinsella
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-04 14:07 9% ` Burakov, Anatoly
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-07 9:48 4% ` Thomas Monjalon
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 9:04 4% ` Ray Kinsella
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 10:15 7% ` Burakov, Anatoly
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:00 4% ` Ray Kinsella
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:38 4% ` Burakov, Anatoly
2019-04-08 13:58 4% ` David Marchand
2019-04-08 13:58 4% ` David Marchand
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:02 4% ` Burakov, Anatoly
2019-04-08 14:38 4% ` David Marchand
2019-04-08 14:38 4% ` David Marchand
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:13 4% ` Stephen Hemminger
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-08 15:49 4% ` Burakov, Anatoly
2019-04-10 8:35 4% ` David Marchand
2019-04-10 8:35 4% ` David Marchand
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-08 15:50 4% ` Burakov, Anatoly
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-09 9:42 4% ` Ray Kinsella
2019-04-14 0:42 9% ` Neil Horman
2019-04-14 0:42 9% ` Neil Horman
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-15 9:10 4% ` Bruce Richardson
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 15:51 8% ` Stephen Hemminger
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:37 4% ` Burakov, Anatoly
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 16:56 7% ` Kevin Traynor
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 19:08 8% ` Wiles, Keith
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-04 20:13 8% ` Kevin Traynor
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:30 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-05 13:29 4% ` Ray Kinsella
2019-04-04 9:47 4% ` [dpdk-dev] " Kevin Traynor
2019-04-04 9:47 4% ` Kevin Traynor
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-04 13:16 7% ` Ray Kinsella
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 5:14 9% ` Honnappa Nagarahalli
2019-04-10 9:03 8% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10 9:03 8% ` Bruce Richardson
2019-04-10 9:43 4% ` [dpdk-dev] " Luca Boccassi
2019-04-10 9:43 4% ` Luca Boccassi
2019-04-03 17:16 [dpdk-dev] [RFC 0/5] make lcore_config less visible Stephen Hemminger
2019-04-03 17:16 9% ` [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-03 17:16 9% ` Stephen Hemminger
2019-04-03 17:16 3% ` [dpdk-dev] [RFC 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-03 17:16 3% ` Stephen Hemminger
2019-04-05 8:17 4% [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion David Marchand
2019-04-05 8:17 4% ` David Marchand
2019-04-05 11:22 0% ` Neil Horman
2019-04-05 11:22 0% ` Neil Horman
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-15 22:14 0% ` Thomas Monjalon
2019-04-05 9:05 3% [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:05 3% ` [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro Qi Zhang
2019-04-05 9:05 3% ` Qi Zhang
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:36 3% ` Ananyev, Konstantin
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 9:42 3% ` Ferruh Yigit
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 10:37 4% ` Thomas Monjalon
2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:12 3% ` Ferruh Yigit
2019-04-05 11:31 0% ` [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type Ferruh Yigit
2019-04-05 11:31 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 11:40 0% ` Ferruh Yigit
2019-04-05 20:30 3% [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
2019-04-05 20:30 3% ` Stephen Hemminger
2019-04-08 18:25 3% [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-08 18:25 3% ` Stephen Hemminger
2019-04-08 18:25 9% ` [dpdk-dev] [PATCH v1 1/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-08 18:25 9% ` Stephen Hemminger
2019-04-08 18:25 4% ` [dpdk-dev] [PATCH v1 5/5] eal: make lcore_config private Stephen Hemminger
2019-04-08 18:25 4% ` Stephen Hemminger
2019-04-10 17:15 4% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 4% ` Stephen Hemminger
2019-04-10 17:16 9% ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-04-10 17:16 9% ` Stephen Hemminger
2019-04-09 17:36 4% [dpdk-dev] [PATCH] doc: add guideines for initial PMD submission Rami Rosen
2019-04-09 17:36 4% ` Rami Rosen
2019-04-10 8:36 5% [dpdk-dev] [PATCH] doc: announce API change for net defines/structs/funcs Olivier Matz
2019-04-10 8:36 5% ` Olivier Matz
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 9:16 0% ` Bruce Richardson
2019-04-10 11:18 [dpdk-dev] [PATCH 00/10] add MACSEC hw offload to atlantic PMD Igor Russkikh
2019-04-10 11:18 ` [dpdk-dev] [PATCH 01/10] ethdev: introduce MACSEC device ops Igor Russkikh
2019-04-12 18:26 ` Ferruh Yigit
2019-04-13 7:24 ` Igor Russkikh
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:43 3% ` Ferruh Yigit
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 9:58 0% ` Andrew Rybchenko
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:11 0% ` Thomas Monjalon
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-16 10:19 0% ` Igor Russkikh
2019-04-11 10:41 1% [dpdk-dev] [RFC PATCH] cmdline: add prefix to numeric type enums Bruce Richardson
2019-04-11 10:41 1% ` Bruce Richardson
2019-04-12 10:13 4% [dpdk-dev] [PATCH V2] doc: add guideines for initial PMD submission Rami Rosen
2019-04-12 10:13 4% ` Rami Rosen
2019-04-12 10:26 4% [dpdk-dev] [PATCH V3] " Rami Rosen
2019-04-12 10:26 4% ` Rami Rosen
2019-04-17 5:12 9% [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 8:36 9% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
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).