* [dpdk-dev] ABI and inline functions
@ 2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 8% ` 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%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 5:12 9% ` Honnappa Nagarahalli
@ 2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 8:36 8% ` Bruce Richardson
` (3 more replies)
1 sibling, 4 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 8%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 8% ` Bruce Richardson
@ 2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 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 8%]
* 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
` (2 more replies)
0 siblings, 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] [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 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 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: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: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] ABI and inline functions
2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 8:36 8% ` Bruce Richardson
@ 2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-18 4:34 9% ` Honnappa Nagarahalli
3 siblings, 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] 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 8% ` Bruce Richardson
2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
@ 2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 4:34 9% ` Honnappa Nagarahalli
3 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-17 17:46 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Wednesday, April 17, 2019 2:07 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] ABI and inline functions
>
> > 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
# I think, we need consider the how fat is the function too,
If it is light weight, probably we need to make it inline
# Except the forward case, In real world use case, it is not trivial make large
burst of packet to process it even though function prototype burst.
We may need to consider that
# For the given function if some argument is used with inline other function,
probably no point in making that function alone inline as the structure
is exposed in some other function.
> * anything what works with single packet at a time should be inline
>
> > 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.
IMO, We have two primary use case for DPDK
1) NFV kind of use case where the application needs to run on multiple platform
without recompiling it.
2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
Controller used. For fixed appliance use case, end user care more of performance
than ABI compatibility as it easy to recompile the end user application vs the cost of
hitting performance impact.
IMO, DPDK needs to cater to both category.
My 2c.
>
> 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 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-17 17:46 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Wednesday, April 17, 2019 2:07 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: Re: [dpdk-dev] ABI and inline functions
>
> > 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
# I think, we need consider the how fat is the function too,
If it is light weight, probably we need to make it inline
# Except the forward case, In real world use case, it is not trivial make large
burst of packet to process it even though function prototype burst.
We may need to consider that
# For the given function if some argument is used with inline other function,
probably no point in making that function alone inline as the structure
is exposed in some other function.
> * anything what works with single packet at a time should be inline
>
> > 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.
IMO, We have two primary use case for DPDK
1) NFV kind of use case where the application needs to run on multiple platform
without recompiling it.
2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
Controller used. For fixed appliance use case, end user care more of performance
than ABI compatibility as it easy to recompile the end user application vs the cost of
hitting performance impact.
IMO, DPDK needs to cater to both category.
My 2c.
>
> 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 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 18:51 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 17:46:34 +0000
Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> > Sent: Wednesday, April 17, 2019 2:07 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> > Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> > Subject: Re: [dpdk-dev] ABI and inline functions
> >
> > > 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
>
> # I think, we need consider the how fat is the function too,
> If it is light weight, probably we need to make it inline
> # Except the forward case, In real world use case, it is not trivial make large
> burst of packet to process it even though function prototype burst.
> We may need to consider that
> # For the given function if some argument is used with inline other function,
> probably no point in making that function alone inline as the structure
> is exposed in some other function.
>
> > * anything what works with single packet at a time should be inline
> >
> > > 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.
>
> IMO, We have two primary use case for DPDK
>
> 1) NFV kind of use case where the application needs to run on multiple platform
> without recompiling it.
> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
> Controller used. For fixed appliance use case, end user care more of performance
> than ABI compatibility as it easy to recompile the end user application vs the cost of
> hitting performance impact.
Nobody cares about compatiablity until they have to the first security update.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
@ 2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-17 18:51 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
On Wed, 17 Apr 2019 17:46:34 +0000
Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> > Sent: Wednesday, April 17, 2019 2:07 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
> > Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> > Subject: Re: [dpdk-dev] ABI and inline functions
> >
> > > 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
>
> # I think, we need consider the how fat is the function too,
> If it is light weight, probably we need to make it inline
> # Except the forward case, In real world use case, it is not trivial make large
> burst of packet to process it even though function prototype burst.
> We may need to consider that
> # For the given function if some argument is used with inline other function,
> probably no point in making that function alone inline as the structure
> is exposed in some other function.
>
> > * anything what works with single packet at a time should be inline
> >
> > > 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.
>
> IMO, We have two primary use case for DPDK
>
> 1) NFV kind of use case where the application needs to run on multiple platform
> without recompiling it.
> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
> Controller used. For fixed appliance use case, end user care more of performance
> than ABI compatibility as it easy to recompile the end user application vs the cost of
> hitting performance impact.
Nobody cares about compatiablity until they have to the first security update.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 8:36 8% ` Bruce Richardson
` (2 preceding siblings ...)
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
@ 2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
3 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-18 4:34 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, Honnappa Nagarahalli, nd, 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.
If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
> 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
I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
> 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.
The new structure members have to be added such that the previous layout is not affected. Either add at the end or use the gaps that are left because of cache line alignment.
>
> 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
Yes, very clear on this.
> 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).
A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
> > 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.
I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
> > 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.
>
I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
> 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-18 4:34 9% ` Honnappa Nagarahalli
@ 2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-18 4:34 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, Honnappa Nagarahalli, nd, 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.
If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
> 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
I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
> 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.
The new structure members have to be added such that the previous layout is not affected. Either add at the end or use the gaps that are left because of cache line alignment.
>
> 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
Yes, very clear on this.
> 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).
A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
> > 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.
I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
> > 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.
>
I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
> 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] [EXT] Re: ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
@ 2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-18 5:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, April 18, 2019 12:21 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
> <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> > 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.
> >
> > IMO, We have two primary use case for DPDK
> >
> > 1) NFV kind of use case where the application needs to run on multiple
> platform
> > without recompiling it.
> > 2) Fixed appliance use case where embed SoC like Intel Denverton or
> > ARM64 integrated Controller used. For fixed appliance use case, end
> > user care more of performance than ABI compatibility as it easy to
> > recompile the end user application vs the cost of hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
For fixed appliance case, The update(FW update) will be a single blob which
Include all the components. So they can back port the security fix and recompile
the sw as needed.
The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-18 5:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, Ray Kinsella, nd
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, April 18, 2019 12:21 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
> <mdr@ashroe.eu>; nd <nd@arm.com>
> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> > 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.
> >
> > IMO, We have two primary use case for DPDK
> >
> > 1) NFV kind of use case where the application needs to run on multiple
> platform
> > without recompiling it.
> > 2) Fixed appliance use case where embed SoC like Intel Denverton or
> > ARM64 integrated Controller used. For fixed appliance use case, end
> > user care more of performance than ABI compatibility as it easy to
> > recompile the end user application vs the cost of hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
For fixed appliance case, The update(FW update) will be a single blob which
Include all the components. So they can back port the security fix and recompile
the sw as needed.
The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
@ 2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Bruce Richardson @ 2019-04-18 10:28 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >
> > 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.
> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
If the application wants the bugfix, then yes. However, if the app is
unaffected by the bug, then it should have the option of updating DPDK
without a recompile.
> >
> > 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
> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
No, there is never any need for two versions of the inline functions, only
the newest version is needed. This is because in the case of a newly compiled
application only the newest version of the non-inline functions is ever
used. The other older versions are only used at runtime for compatilibity
with pre-compiled apps with the older inlines.
> >
> > 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.
> The new structure members have to be added such that the previous layout
> is not affected. Either add at the end or use the gaps that are left
> because of cache line alignment.
>
Not necessarily. There is nothing that requires the older and newer
versions of a function to use the same structure. We can rename the
original structure when versioning the old function, and then create a new
structure with the original name for later recompiled code using the newest
ABIs.
> >
> > 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
> Yes, very clear on this.
>
> > 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).
> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
Yes, I would tend to agree in general. The other thing is the frequency of
calls, and - as already stated - whether it takes a burst of not. Because
even if it's a trivial function that takes only 10 cycles and we want to
uninline it, the cost may double; but if it takes a burst of packets and is
only used once/twice per burst the cost per packet should still only be a
fraction of a cycle.
> >
> > > 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.
> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
Having multiple LTS's per distro would be nice, but it's putting a lot more
work on the distro folks, I think.
> >
> > > 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.
> >
> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>
The trouble here is that a DPDK release, as a product is either backward
compatible or not. Either a user can take it as a drop-in replacement for
the previous version or not. Users do not want to have to go through a
checklist for each app to see if the app uses only "compatible" APIs or
not. Same for the distro folks, they are not going to take some libs from a
release but not others because the ABI is broken for some but not others.
Regards,
/Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
@ 2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-18 10:28 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >
> > 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.
> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>
If the application wants the bugfix, then yes. However, if the app is
unaffected by the bug, then it should have the option of updating DPDK
without a recompile.
> >
> > 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
> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>
No, there is never any need for two versions of the inline functions, only
the newest version is needed. This is because in the case of a newly compiled
application only the newest version of the non-inline functions is ever
used. The other older versions are only used at runtime for compatilibity
with pre-compiled apps with the older inlines.
> >
> > 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.
> The new structure members have to be added such that the previous layout
> is not affected. Either add at the end or use the gaps that are left
> because of cache line alignment.
>
Not necessarily. There is nothing that requires the older and newer
versions of a function to use the same structure. We can rename the
original structure when versioning the old function, and then create a new
structure with the original name for later recompiled code using the newest
ABIs.
> >
> > 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
> Yes, very clear on this.
>
> > 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).
> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>
Yes, I would tend to agree in general. The other thing is the frequency of
calls, and - as already stated - whether it takes a burst of not. Because
even if it's a trivial function that takes only 10 cycles and we want to
uninline it, the cost may double; but if it takes a burst of packets and is
only used once/twice per burst the cost per packet should still only be a
fraction of a cycle.
> >
> > > 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.
> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>
Having multiple LTS's per distro would be nice, but it's putting a lot more
work on the distro folks, I think.
> >
> > > 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.
> >
> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>
The trouble here is that a DPDK release, as a product is either backward
compatible or not. Either a user can take it as a drop-in replacement for
the previous version or not. Users do not want to have to go through a
checklist for each app to see if the app uses only "compatible" APIs or
not. Same for the distro folks, they are not going to take some libs from a
release but not others because the ABI is broken for some but not others.
Regards,
/Bruce
^ permalink raw reply [relevance 7%]
* [dpdk-dev] DPDK Release Status Meeting 18/4/2019
@ 2019-04-18 10:58 3% Ferruh Yigit
2019-04-18 10:58 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-18 10:58 UTC (permalink / raw)
To: dpdk-dev
Cc: John McNamara, Stokes, Ian, Thomas Monjalon, Jerin Jacob, Akhil,
Goyal, Cristian Dumitrescu, Qian Xu, Yongseok Koh,
Maxime Coquelin, Qi Zhang, Shahaf Shuler, Pablo de Lara
Minutes 18 April 2019
---------------------
Agenda:
* Release Dates
* RC1 status
* Subtrees
* OvS
* Opens
Participants:
* Arm
* Debian
* Intel
* Mellanox
* RedHat
Release Dates
-------------
* v19.05 dates, RC2 date pushed to Friday:
* RC2: *Friday, 19 April*
* RC3: Monday , 29 April
* Release: Friday, 10 May
* v19.08 dates:
* Proposal/V1 Monday 03 June 2019
* Integration/Merge/RC1 Monday 01 July 2019
* Release Thurs 01 August 2019
* Schedule updated on roadmap page:
https://core.dpdk.org/roadmap/
* v19.11 proposed dates, please comment.
* Proposal/V1 Friday 06 September 2019
* Integration/Merge/RC1 Friday 11 October 2019
* Release Friday 08 November 2019
* Constrains:
* PRC holidays on October 1-7 inclusive, rc1 shouldn't overlap with it
* US DPDK Summit on mid November, better to have release before summit
* Some historical .11 release dates data:
17.08: Tue Aug 8
17.11-rc1: Sat Oct 14 (9 weeks and 4 days)
17.11: Wed Nov 15 (4 weeks and 4 days)
Overall 17.11 release took: 14 weeks and 1 day
18.08: Thu Aug 9
18.11-rc1: Mon Oct 29 (11 weeks and 4 days)
18.11: Mon Nov 26 (4 weeks)
Overall 18.11 release took: 15 weeks and 4 days
RC1 status
----------
* RC1 Intel test results looks good, no major issue detected
Subtrees
--------
* main
* Merged timer library
* For RCU there are questions around API/ABI stability (inline functions)
Leaning to merge as it is
* next-net
* Ready for rc2, some waiting fixes can go in after rc2
* If atlantic macsec patches makes on time, can go in rc2
* Remaining patches won't be able to make the release
* next-virtio
* Tree prepared for rc2 and merged into next-net
* next-crypto
* Akhil get some patches today/tomorrow
* Will be ready for rc2
* next-eventdev
* next-pipeline
* next-qos
* No update, we need attendance from maintainers
* Stable trees
* No update
OvS
---
* OvS master/2.11.x release agreed to move 18.11.1
* For DPDK 17.11, OvS decided to skip 17.11.5 and use 17.11.6 since it
is close to be released
* OvS testing on DPDK Community Lab is up now,
The discussion is which version of OvS and DPDK to use, using top of
development branch for both right now, should stick a fixed version for
OvS?
* af_xdp support on OvS proposed, there were some patches for it
Opens
-----
* Akhil is looking for co-maintainer for crypto sub-tree
* Coverity is up and there are already some fixes hit the mail list,
this is good progress, as a reminder, coverity dpdk project link:
https://scan.coverity.com/projects/dpdk-data-plane-development-kit?tab=overview
* A patch to fix all document spelling errors has been sent by John,
there will be new version of it
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Release Status Meeting 18/4/2019
2019-04-18 10:58 3% [dpdk-dev] DPDK Release Status Meeting 18/4/2019 Ferruh Yigit
@ 2019-04-18 10:58 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-18 10:58 UTC (permalink / raw)
To: dpdk-dev
Cc: John McNamara, Stokes, Ian, Thomas Monjalon, Jerin Jacob, Akhil,
Goyal, Cristian Dumitrescu, Qian Xu, Yongseok Koh,
Maxime Coquelin, Qi Zhang, Shahaf Shuler, Pablo de Lara
Minutes 18 April 2019
---------------------
Agenda:
* Release Dates
* RC1 status
* Subtrees
* OvS
* Opens
Participants:
* Arm
* Debian
* Intel
* Mellanox
* RedHat
Release Dates
-------------
* v19.05 dates, RC2 date pushed to Friday:
* RC2: *Friday, 19 April*
* RC3: Monday , 29 April
* Release: Friday, 10 May
* v19.08 dates:
* Proposal/V1 Monday 03 June 2019
* Integration/Merge/RC1 Monday 01 July 2019
* Release Thurs 01 August 2019
* Schedule updated on roadmap page:
https://core.dpdk.org/roadmap/
* v19.11 proposed dates, please comment.
* Proposal/V1 Friday 06 September 2019
* Integration/Merge/RC1 Friday 11 October 2019
* Release Friday 08 November 2019
* Constrains:
* PRC holidays on October 1-7 inclusive, rc1 shouldn't overlap with it
* US DPDK Summit on mid November, better to have release before summit
* Some historical .11 release dates data:
17.08: Tue Aug 8
17.11-rc1: Sat Oct 14 (9 weeks and 4 days)
17.11: Wed Nov 15 (4 weeks and 4 days)
Overall 17.11 release took: 14 weeks and 1 day
18.08: Thu Aug 9
18.11-rc1: Mon Oct 29 (11 weeks and 4 days)
18.11: Mon Nov 26 (4 weeks)
Overall 18.11 release took: 15 weeks and 4 days
RC1 status
----------
* RC1 Intel test results looks good, no major issue detected
Subtrees
--------
* main
* Merged timer library
* For RCU there are questions around API/ABI stability (inline functions)
Leaning to merge as it is
* next-net
* Ready for rc2, some waiting fixes can go in after rc2
* If atlantic macsec patches makes on time, can go in rc2
* Remaining patches won't be able to make the release
* next-virtio
* Tree prepared for rc2 and merged into next-net
* next-crypto
* Akhil get some patches today/tomorrow
* Will be ready for rc2
* next-eventdev
* next-pipeline
* next-qos
* No update, we need attendance from maintainers
* Stable trees
* No update
OvS
---
* OvS master/2.11.x release agreed to move 18.11.1
* For DPDK 17.11, OvS decided to skip 17.11.5 and use 17.11.6 since it
is close to be released
* OvS testing on DPDK Community Lab is up now,
The discussion is which version of OvS and DPDK to use, using top of
development branch for both right now, should stick a fixed version for
OvS?
* af_xdp support on OvS proposed, there were some patches for it
Opens
-----
* Akhil is looking for co-maintainer for crypto sub-tree
* Coverity is up and there are already some fixes hit the mail list,
this is good progress, as a reminder, coverity dpdk project link:
https://scan.coverity.com/projects/dpdk-data-plane-development-kit?tab=overview
* A patch to fix all document spelling errors has been sent by John,
there will be new version of it
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
@ 2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
0 siblings, 2 replies; 200+ results
From: Adrien Mazarguil @ 2019-04-18 12:30 UTC (permalink / raw)
To: Dekel Peled
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, yskoh, shahafs,
arybchenko, dev, orika
On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> Add actions:
> - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP header.
> - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> header.
> - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> header.
>
> Original work by Xiaoyu Min.
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Almost there... Some changes were not made as discussed, please see below.
<snip>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 0203f4f..fc234de 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
> | ``mac_addr`` | MAC address |
> +--------------+---------------+
>
> +Action: ``INC_TCP_SEQ``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Increase sequence number in the outermost TCP header.
> +
> +Using this action on non-matching traffic will result in undefined behavior,
> +depending on PMD implementation.
OK, "depending on PMD implementation" looks a bit redundant though.
> +
> +.. _table_rte_flow_action_inc_tcp_seq:
> +
> +.. table:: INC_TCP_SEQ
> +
> + +-----------+------------------------------------------+
> + | Field | Value |
> + +===========+==========================================+
> + | ``value`` | Value to increase TCP sequence number by |
> + +-----------+------------------------------------------+
Configuration object documentation needs updating since you changed its type
and fields.
These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and DEC_TCP_ACK.
<snip>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index c0fe879..e3f6210 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> * See struct rte_flow_action_set_mac.
> */
> RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> +
> + /**
> + * Increase sequence number in the outermost TCP header.
> + *
> + * Using this action on non-matching traffic will result in
> + * undefined behavior, depending on PMD implementation.
"depending on PMD implementation" also redundant here.
<snip>
> /*
> + * @warning
> + * @b EXPERIMENTAL: this union may change without prior notice
> + *
> + * General integer type, can be expanded as needed.
> + */
> +union rte_flow_integer {
> + rte_be32_t be32;
> +};
You must include the extra fields you don't use (64/16/32/8 and
le/be/host/signed variants as described in previous messages) to limit the
risk of ABI breakage next time someone needs a field that isn't there yet.
This object must be able to accommodate the largest supported integer and
have the proper alignment constraints for any of these types, hence the
union with all of them from the start.
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * General struct, for use by actions that require a single integer value.
> + */
> +struct rte_flow_general_action {
> + union rte_flow_integer integer;
> +};
Seriously, why can't actions take "union rte_flow_integer" directly? Besides
"rte_flow_general_action" is vague as heck.
Seems like you made this structure so it could be extended later, but forgot
that doing so is not an option since ABIs are set in stone. You must make
new APIs as exhaustive and restrict their scope as much as possible from the
start because of that.
Note if you don't want to use union rte_flow_integer directly, it's also
fine to document your actions as taking (const rte_be32_t *) directly
through their conf pointer.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-18 12:30 3% ` Adrien Mazarguil
@ 2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
1 sibling, 0 replies; 200+ results
From: Adrien Mazarguil @ 2019-04-18 12:30 UTC (permalink / raw)
To: Dekel Peled
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, yskoh, shahafs,
arybchenko, dev, orika
On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> Add actions:
> - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP header.
> - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> header.
> - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> header.
>
> Original work by Xiaoyu Min.
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Almost there... Some changes were not made as discussed, please see below.
<snip>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 0203f4f..fc234de 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned.
> | ``mac_addr`` | MAC address |
> +--------------+---------------+
>
> +Action: ``INC_TCP_SEQ``
> +^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Increase sequence number in the outermost TCP header.
> +
> +Using this action on non-matching traffic will result in undefined behavior,
> +depending on PMD implementation.
OK, "depending on PMD implementation" looks a bit redundant though.
> +
> +.. _table_rte_flow_action_inc_tcp_seq:
> +
> +.. table:: INC_TCP_SEQ
> +
> + +-----------+------------------------------------------+
> + | Field | Value |
> + +===========+==========================================+
> + | ``value`` | Value to increase TCP sequence number by |
> + +-----------+------------------------------------------+
Configuration object documentation needs updating since you changed its type
and fields.
These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and DEC_TCP_ACK.
<snip>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index c0fe879..e3f6210 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> * See struct rte_flow_action_set_mac.
> */
> RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> +
> + /**
> + * Increase sequence number in the outermost TCP header.
> + *
> + * Using this action on non-matching traffic will result in
> + * undefined behavior, depending on PMD implementation.
"depending on PMD implementation" also redundant here.
<snip>
> /*
> + * @warning
> + * @b EXPERIMENTAL: this union may change without prior notice
> + *
> + * General integer type, can be expanded as needed.
> + */
> +union rte_flow_integer {
> + rte_be32_t be32;
> +};
You must include the extra fields you don't use (64/16/32/8 and
le/be/host/signed variants as described in previous messages) to limit the
risk of ABI breakage next time someone needs a field that isn't there yet.
This object must be able to accommodate the largest supported integer and
have the proper alignment constraints for any of these types, hence the
union with all of them from the start.
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * General struct, for use by actions that require a single integer value.
> + */
> +struct rte_flow_general_action {
> + union rte_flow_integer integer;
> +};
Seriously, why can't actions take "union rte_flow_integer" directly? Besides
"rte_flow_general_action" is vague as heck.
Seems like you made this structure so it could be extended later, but forgot
that doing so is not an option since ABIs are set in stone. You must make
new APIs as exhaustive and restrict their scope as much as possible from the
start because of that.
Note if you don't want to use union rte_flow_integer directly, it's also
fine to document your actions as taking (const rte_be32_t *) directly
through their conf pointer.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK techboard minutes (2019-04-10)
@ 2019-04-18 20:41 5% Olivier Matz
2019-04-18 20:41 5% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-04-18 20:41 UTC (permalink / raw)
To: dev; +Cc: DPDK Techboard
Hi,
Here are the meeting notes of the DPDK technical board meeting held on
2019-04-10.
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
1) DPDK development process and tools survey
============================================
Reference: https://mails.dpdk.org/archives/dev/2019-March/126114.html
The objective of the survey is to detect problems (if any) in our
current process.
- The survey is now closed.
- Unfortunately the number of received responses is low compared to the
number of active DPDK developers.
- The answers and feedback will be gathered and summarized by mail.
- There will be a Q&A session on this topic at next Europe DPDK summit.
2) DPDK API Stability discussion
================================
Reference: https://mails.dpdk.org/archives/dev/2019-April/128969.html
- Following the discussion on the ML, there is a consensus that API/ABI
stability is a direction where the DPDK project should head for.
- Adding automated tools to check API/ABI stability is a good first step.
Here is a list of ABI checker tools:
- ABI Laboratory: https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
- https://sourceware.org/libabigail
- https://lvc.github.io/abi-compliance-checker
- The current dpdk tool, validate-abi.sh, is based on abi-compliance-checker.
- Patches like this one proposed by Stephen Hemminger should be generalized
to other parts of DPDK (everything that is not rx/tx path):
http://patches.dpdk.org/project/dpdk/list/?series=4248
- An "ABI/API stability" item will be added to techboard recurring topics.
- The documentation (guides/contributing/versioning,
guides/contributing/design) and website (including roadmap) should be
updated to highlight and explain the intent (Ray proposed himself).
- No calendar/deadlines was decided, let's discuss it again at next
techboard meeting.
3) SPDX licenses
================
There are still some old license headers in Intel driver base code, they
will be replaced by new shared code drops.
^ permalink raw reply [relevance 5%]
* [dpdk-dev] DPDK techboard minutes (2019-04-10)
2019-04-18 20:41 5% [dpdk-dev] DPDK techboard minutes (2019-04-10) Olivier Matz
@ 2019-04-18 20:41 5% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-04-18 20:41 UTC (permalink / raw)
To: dev; +Cc: DPDK Techboard
Hi,
Here are the meeting notes of the DPDK technical board meeting held on
2019-04-10.
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob
- Konstantin Ananyev
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
1) DPDK development process and tools survey
============================================
Reference: https://mails.dpdk.org/archives/dev/2019-March/126114.html
The objective of the survey is to detect problems (if any) in our
current process.
- The survey is now closed.
- Unfortunately the number of received responses is low compared to the
number of active DPDK developers.
- The answers and feedback will be gathered and summarized by mail.
- There will be a Q&A session on this topic at next Europe DPDK summit.
2) DPDK API Stability discussion
================================
Reference: https://mails.dpdk.org/archives/dev/2019-April/128969.html
- Following the discussion on the ML, there is a consensus that API/ABI
stability is a direction where the DPDK project should head for.
- Adding automated tools to check API/ABI stability is a good first step.
Here is a list of ABI checker tools:
- ABI Laboratory: https://abi-laboratory.pro/index.php?view=timeline&l=dpdk
- https://sourceware.org/libabigail
- https://lvc.github.io/abi-compliance-checker
- The current dpdk tool, validate-abi.sh, is based on abi-compliance-checker.
- Patches like this one proposed by Stephen Hemminger should be generalized
to other parts of DPDK (everything that is not rx/tx path):
http://patches.dpdk.org/project/dpdk/list/?series=4248
- An "ABI/API stability" item will be added to techboard recurring topics.
- The documentation (guides/contributing/versioning,
guides/contributing/design) and website (including roadmap) should be
updated to highlight and explain the intent (Ray proposed himself).
- No calendar/deadlines was decided, let's discuss it again at next
techboard meeting.
3) SPDX licenses
================
There are still some old license headers in Intel driver base code, they
will be replaced by new shared code drops.
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
@ 2019-04-22 7:15 0% ` Dekel Peled
2019-04-22 7:15 0% ` Dekel Peled
1 sibling, 1 reply; 200+ results
From: Dekel Peled @ 2019-04-22 7:15 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, Yongseok Koh,
Shahaf Shuler, arybchenko, dev, Ori Kam
Thanks, PSB.
> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Sent: Thursday, April 18, 2019 3:31 PM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: wenzhuo.lu@intel.com; jingjing.wu@intel.com;
> bernard.iremonger@intel.com; Yongseok Koh <yskoh@mellanox.com>;
> Shahaf Shuler <shahafs@mellanox.com>; arybchenko@solarflare.com;
> dev@dpdk.org; Ori Kam <orika@mellanox.com>
> Subject: Re: [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
>
> On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> > Add actions:
> > - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> > - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP
> header.
> > - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> > header.
> > - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> > header.
> >
> > Original work by Xiaoyu Min.
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>
> Almost there... Some changes were not made as discussed, please see
> below.
>
> <snip>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 0203f4f..fc234de 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION
> error will be returned.
> > | ``mac_addr`` | MAC address |
> > +--------------+---------------+
> >
> > +Action: ``INC_TCP_SEQ``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Increase sequence number in the outermost TCP header.
> > +
> > +Using this action on non-matching traffic will result in undefined
> > +behavior, depending on PMD implementation.
>
> OK, "depending on PMD implementation" looks a bit redundant though.
Fine, will remove it.
>
> > +
> > +.. _table_rte_flow_action_inc_tcp_seq:
> > +
> > +.. table:: INC_TCP_SEQ
> > +
> > + +-----------+------------------------------------------+
> > + | Field | Value |
> > +
> +===========+==========================================+
> > + | ``value`` | Value to increase TCP sequence number by |
> > + +-----------+------------------------------------------+
>
> Configuration object documentation needs updating since you changed its
> type and fields.
>
> These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and
> DEC_TCP_ACK.
Will update.
>
> <snip>
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index c0fe879..e3f6210 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> > * See struct rte_flow_action_set_mac.
> > */
> > RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> > +
> > + /**
> > + * Increase sequence number in the outermost TCP header.
> > + *
> > + * Using this action on non-matching traffic will result in
> > + * undefined behavior, depending on PMD implementation.
>
> "depending on PMD implementation" also redundant here.
>
> <snip>
> > /*
> > + * @warning
> > + * @b EXPERIMENTAL: this union may change without prior notice
> > + *
> > + * General integer type, can be expanded as needed.
> > + */
> > +union rte_flow_integer {
> > + rte_be32_t be32;
> > +};
>
> You must include the extra fields you don't use (64/16/32/8 and
> le/be/host/signed variants as described in previous messages) to limit the
> risk of ABI breakage next time someone needs a field that isn't there yet.
>
> This object must be able to accommodate the largest supported integer and
> have the proper alignment constraints for any of these types, hence the
> union with all of them from the start.
I will add required fields for 8, 16 and 32 bits.
Adding 64 bit fields will inflate the union size, wasting memory.
It should be handled separately in specific cases.
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * General struct, for use by actions that require a single integer value.
> > + */
> > +struct rte_flow_general_action {
> > + union rte_flow_integer integer;
> > +};
>
> Seriously, why can't actions take "union rte_flow_integer" directly? Besides
> "rte_flow_general_action" is vague as heck.
>
I prefer to follow the existing convention, where actions take struct even if it contains a single field.
I will define the union unnamed in the struct.
I will rename to rte_flow_integer_action.
> Seems like you made this structure so it could be extended later, but forgot
> that doing so is not an option since ABIs are set in stone. You must make new
> APIs as exhaustive and restrict their scope as much as possible from the start
> because of that.
>
> Note if you don't want to use union rte_flow_integer directly, it's also fine to
> document your actions as taking (const rte_be32_t *) directly through their
> conf pointer.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
2019-04-22 7:15 0% ` Dekel Peled
@ 2019-04-22 7:15 0% ` Dekel Peled
0 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2019-04-22 7:15 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: wenzhuo.lu, jingjing.wu, bernard.iremonger, Yongseok Koh,
Shahaf Shuler, arybchenko, dev, Ori Kam
Thanks, PSB.
> -----Original Message-----
> From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Sent: Thursday, April 18, 2019 3:31 PM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: wenzhuo.lu@intel.com; jingjing.wu@intel.com;
> bernard.iremonger@intel.com; Yongseok Koh <yskoh@mellanox.com>;
> Shahaf Shuler <shahafs@mellanox.com>; arybchenko@solarflare.com;
> dev@dpdk.org; Ori Kam <orika@mellanox.com>
> Subject: Re: [PATCH v4 1/3] ethdev: add actions to modify TCP header fields
>
> On Wed, Apr 10, 2019 at 02:50:41PM +0300, Dekel Peled wrote:
> > Add actions:
> > - INC_TCP_SEQ - Increase sequence number in the outermost TCP header.
> > - DEC_TCP_SEQ - Decrease sequence number in the outermost TCP
> header.
> > - INC_TCP_ACK - Increase acknowledgment number in the outermost TCP
> > header.
> > - DEC_TCP_ACK - Decrease acknowledgment number in the outermost TCP
> > header.
> >
> > Original work by Xiaoyu Min.
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
>
> Almost there... Some changes were not made as discussed, please see
> below.
>
> <snip>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 0203f4f..fc234de 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -2345,6 +2345,78 @@ Otherwise, RTE_FLOW_ERROR_TYPE_ACTION
> error will be returned.
> > | ``mac_addr`` | MAC address |
> > +--------------+---------------+
> >
> > +Action: ``INC_TCP_SEQ``
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Increase sequence number in the outermost TCP header.
> > +
> > +Using this action on non-matching traffic will result in undefined
> > +behavior, depending on PMD implementation.
>
> OK, "depending on PMD implementation" looks a bit redundant though.
Fine, will remove it.
>
> > +
> > +.. _table_rte_flow_action_inc_tcp_seq:
> > +
> > +.. table:: INC_TCP_SEQ
> > +
> > + +-----------+------------------------------------------+
> > + | Field | Value |
> > +
> +===========+==========================================+
> > + | ``value`` | Value to increase TCP sequence number by |
> > + +-----------+------------------------------------------+
>
> Configuration object documentation needs updating since you changed its
> type and fields.
>
> These comments also apply to DEC_TCP_SEQ, INC_TCP_ACK and
> DEC_TCP_ACK.
Will update.
>
> <snip>
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index c0fe879..e3f6210 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1651,6 +1651,46 @@ enum rte_flow_action_type {
> > * See struct rte_flow_action_set_mac.
> > */
> > RTE_FLOW_ACTION_TYPE_SET_MAC_DST,
> > +
> > + /**
> > + * Increase sequence number in the outermost TCP header.
> > + *
> > + * Using this action on non-matching traffic will result in
> > + * undefined behavior, depending on PMD implementation.
>
> "depending on PMD implementation" also redundant here.
>
> <snip>
> > /*
> > + * @warning
> > + * @b EXPERIMENTAL: this union may change without prior notice
> > + *
> > + * General integer type, can be expanded as needed.
> > + */
> > +union rte_flow_integer {
> > + rte_be32_t be32;
> > +};
>
> You must include the extra fields you don't use (64/16/32/8 and
> le/be/host/signed variants as described in previous messages) to limit the
> risk of ABI breakage next time someone needs a field that isn't there yet.
>
> This object must be able to accommodate the largest supported integer and
> have the proper alignment constraints for any of these types, hence the
> union with all of them from the start.
I will add required fields for 8, 16 and 32 bits.
Adding 64 bit fields will inflate the union size, wasting memory.
It should be handled separately in specific cases.
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * General struct, for use by actions that require a single integer value.
> > + */
> > +struct rte_flow_general_action {
> > + union rte_flow_integer integer;
> > +};
>
> Seriously, why can't actions take "union rte_flow_integer" directly? Besides
> "rte_flow_general_action" is vague as heck.
>
I prefer to follow the existing convention, where actions take struct even if it contains a single field.
I will define the union unnamed in the struct.
I will rename to rte_flow_integer_action.
> Seems like you made this structure so it could be extended later, but forgot
> that doing so is not an option since ABIs are set in stone. You must make new
> APIs as exhaustive and restrict their scope as much as possible from the start
> because of that.
>
> Note if you don't want to use union rte_flow_integer directly, it's also fine to
> document your actions as taking (const rte_be32_t *) directly through their
> conf pointer.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
@ 2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Neil Horman @ 2019-04-22 11:34 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Fri, Apr 19, 2019 at 11:21:37PM +0200, Mattias Rönnblom wrote:
> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native
> combined Linear Feedback Shift Register (LFSR) (also known as
> Tausworthe) pseudo-number generator, with five sequences.
>
> This generator is faster and produces better quality random numbers
> than libc's lrand48() implementation. This implementation, as opposed
> to lrand48(), is multi-thread safe in regards to concurrent rte_rand()
> calls from different lcore threads. It is not cryptographically
> secure - just like lrand48().
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> ---
> lib/librte_eal/common/include/rte_random.h | 29 ++---
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_eal/common/rte_random.c | 137 +++++++++++++++++++++
> lib/librte_eal/freebsd/eal/Makefile | 1 +
> lib/librte_eal/freebsd/eal/eal.c | 2 -
> lib/librte_eal/linux/eal/Makefile | 1 +
> lib/librte_eal/linux/eal/eal.c | 2 -
> lib/librte_eal/rte_eal_version.map | 2 +
> 8 files changed, 153 insertions(+), 22 deletions(-)
> create mode 100644 lib/librte_eal/common/rte_random.c
>
> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h
> index b2ca1c209..66dfe8ae7 100644
> --- a/lib/librte_eal/common/include/rte_random.h
> +++ b/lib/librte_eal/common/include/rte_random.h
> @@ -16,7 +16,6 @@ extern "C" {
> #endif
>
> #include <stdint.h>
> -#include <stdlib.h>
>
> /**
> * Seed the pseudo-random generator.
> @@ -25,34 +24,28 @@ extern "C" {
> * value. It may need to be re-seeded by the user with a real random
> * value.
> *
> + * This function is not multi-thread safe in regards to other
> + * rte_srand() calls, nor is it in relation to concurrent rte_rand()
> + * calls.
> + *
> * @param seedval
> * The value of the seed.
> */
> -static inline void
> -rte_srand(uint64_t seedval)
> -{
> - srand48((long)seedval);
> -}
> +void
> +rte_srand(uint64_t seedval);
>
> /**
> * Get a pseudo-random value.
> *
> - * This function generates pseudo-random numbers using the linear
> - * congruential algorithm and 48-bit integer arithmetic, called twice
> - * to generate a 64-bit value.
> + * The generator is not cryptographically secure.
> + *
> + * If called from lcore threads, this function is thread-safe.
> *
> * @return
> * A pseudo-random value between 0 and (1<<64)-1.
> */
> -static inline uint64_t
> -rte_rand(void)
> -{
> - uint64_t val;
> - val = (uint64_t)lrand48();
> - val <<= 32;
> - val += (uint64_t)lrand48();
> - return val;
> -}
> +uint64_t
> +rte_rand(void);
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
> index 0670e4102..bafd23207 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -35,6 +35,7 @@ common_sources = files(
> 'rte_keepalive.c',
> 'rte_malloc.c',
> 'rte_option.c',
> + 'rte_random.c',
> 'rte_reciprocal.c',
> 'rte_service.c'
> )
> diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
> new file mode 100644
> index 000000000..288e7b8c5
> --- /dev/null
> +++ b/lib/librte_eal/common/rte_random.c
> @@ -0,0 +1,137 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2019 Ericsson AB
> + */
> +
> +#include <stdlib.h>
> +
> +#include <rte_cycles.h>
> +#include <rte_eal.h>
> +#include <rte_lcore.h>
> +#include <rte_random.h>
> +
> +struct rte_rand_state {
> + uint64_t z1;
> + uint64_t z2;
> + uint64_t z3;
> + uint64_t z4;
> + uint64_t z5;
> +} __rte_cache_aligned;
> +
> +static struct rte_rand_state rand_states[RTE_MAX_LCORE];
> +
> +static uint32_t
> +__rte_rand_lcg32(uint32_t *seed)
> +{
> + *seed = 1103515245U * *seed + 12345U;
> +
> + return *seed;
> +}
> +
> +static uint64_t
> +__rte_rand_lcg64(uint32_t *seed)
> +{
> + uint64_t low;
> + uint64_t high;
> +
> + /* A 64-bit LCG would have been much cleaner, but well-known
> + * good multiplier/increments seem hard to come by.
> + */
> +
> + low = __rte_rand_lcg32(seed);
> + high = __rte_rand_lcg32(seed);
> +
> + return low | (high << 32);
> +}
> +
> +static uint64_t
> +__rte_rand_lfsr258_gen_seed(uint32_t *seed, uint64_t min_value)
> +{
> + uint64_t res;
> +
> + res = __rte_rand_lcg64(seed);
> +
> + if (res < min_value)
> + res += min_value;
> +
> + return res;
> +}
> +
> +static void
> +__rte_srand_lfsr258(uint64_t seed, struct rte_rand_state *state)
> +{
> + uint32_t lcg_seed;
> +
> + lcg_seed = (uint32_t)(seed ^ (seed >> 32));
> +
> + state->z1 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 2UL);
> + state->z2 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 512UL);
> + state->z3 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 4096UL);
> + state->z4 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 131072UL);
> + state->z5 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 8388608UL);
> +}
> +
> +void __rte_experimental
> +rte_srand(uint64_t seed)
> +{
> + unsigned int lcore_id;
> +
> + /* add lcore_id to seed to avoid having the same sequence */
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> + __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
> +}
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258_comp(uint64_t z, uint64_t a, uint64_t b, uint64_t c,
> + uint64_t d)
> +{
> + return ((z & c) << d) ^ (((z << a) ^ z) >> b);
> +}
> +
> +/* Based on L’Ecuyer, P.: Tables of maximally equidistributed combined
> + * LFSR generators.
> + */
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258(struct rte_rand_state *state)
> +{
> + state->z1 = __rte_rand_lfsr258_comp(state->z1, 1UL, 53UL,
> + 18446744073709551614UL, 10UL);
> + state->z2 = __rte_rand_lfsr258_comp(state->z2, 24UL, 50UL,
> + 18446744073709551104UL, 5UL);
> + state->z3 = __rte_rand_lfsr258_comp(state->z3, 3UL, 23UL,
> + 18446744073709547520UL, 29UL);
> + state->z4 = __rte_rand_lfsr258_comp(state->z4, 5UL, 24UL,
> + 18446744073709420544UL, 23UL);
> + state->z5 = __rte_rand_lfsr258_comp(state->z5, 3UL, 33UL,
> + 18446744073701163008UL, 8UL);
> +
> + return state->z1 ^ state->z2 ^ state->z3 ^ state->z4 ^ state->z5;
> +}
> +
> +static __rte_always_inline
> +struct rte_rand_state *__rte_rand_get_state(void)
> +{
> + unsigned int lcore_id;
> +
> + lcore_id = rte_lcore_id();
> +
> + if (unlikely(lcore_id == LCORE_ID_ANY))
> + lcore_id = rte_get_master_lcore();
> +
> + return &rand_states[lcore_id];
> +}
> +
> +uint64_t __rte_experimental
> +rte_rand(void)
Do you really want to mark this as experimental? I know it will trigger the
symbol checker with a warning if you don't, but this function already existed
previously and was accepted as part of the ABI. Given that the prototype hasn't
changed, I think you just need to accept it as a non-experimental function
> +{
> + struct rte_rand_state *state;
> +
> + state = __rte_rand_get_state();
> +
> + return __rte_rand_lfsr258(state);
> +}
> +
> +RTE_INIT(rte_rand_init)
> +{
> + rte_srand(rte_get_timer_cycles());
> +}
> diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
> index 19854ee2c..ca616c480 100644
> --- a/lib/librte_eal/freebsd/eal/Makefile
> +++ b/lib/librte_eal/freebsd/eal/Makefile
> @@ -69,6 +69,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
> index c6ac9028f..5d43310b3 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -727,8 +727,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> /* in secondary processes, memory init may allocate additional fbarrays
> * not present in primary processes, so to avoid any potential issues,
> * initialize memzones first.
> diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
> index 6e5261152..729795a10 100644
> --- a/lib/librte_eal/linux/eal/Makefile
> +++ b/lib/librte_eal/linux/eal/Makefile
> @@ -77,6 +77,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index f7ae62d7b..c2bdf0a67 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -1083,8 +1083,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0) {
> rte_eal_init_alert("Cannot init logging.");
> rte_errno = ENOMEM;
> diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
> index d6e375135..0d60668fa 100644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -366,10 +366,12 @@ EXPERIMENTAL {
> rte_mp_request_async;
> rte_mp_sendmsg;
> rte_option_register;
> + rte_rand;
> rte_realloc_socket;
> rte_service_lcore_attr_get;
> rte_service_lcore_attr_reset_all;
> rte_service_may_be_active;
> rte_socket_count;
> rte_socket_id_by_idx;
> + rte_srand;
> };
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
@ 2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-04-22 11:34 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Fri, Apr 19, 2019 at 11:21:37PM +0200, Mattias Rönnblom wrote:
> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native
> combined Linear Feedback Shift Register (LFSR) (also known as
> Tausworthe) pseudo-number generator, with five sequences.
>
> This generator is faster and produces better quality random numbers
> than libc's lrand48() implementation. This implementation, as opposed
> to lrand48(), is multi-thread safe in regards to concurrent rte_rand()
> calls from different lcore threads. It is not cryptographically
> secure - just like lrand48().
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> ---
> lib/librte_eal/common/include/rte_random.h | 29 ++---
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_eal/common/rte_random.c | 137 +++++++++++++++++++++
> lib/librte_eal/freebsd/eal/Makefile | 1 +
> lib/librte_eal/freebsd/eal/eal.c | 2 -
> lib/librte_eal/linux/eal/Makefile | 1 +
> lib/librte_eal/linux/eal/eal.c | 2 -
> lib/librte_eal/rte_eal_version.map | 2 +
> 8 files changed, 153 insertions(+), 22 deletions(-)
> create mode 100644 lib/librte_eal/common/rte_random.c
>
> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h
> index b2ca1c209..66dfe8ae7 100644
> --- a/lib/librte_eal/common/include/rte_random.h
> +++ b/lib/librte_eal/common/include/rte_random.h
> @@ -16,7 +16,6 @@ extern "C" {
> #endif
>
> #include <stdint.h>
> -#include <stdlib.h>
>
> /**
> * Seed the pseudo-random generator.
> @@ -25,34 +24,28 @@ extern "C" {
> * value. It may need to be re-seeded by the user with a real random
> * value.
> *
> + * This function is not multi-thread safe in regards to other
> + * rte_srand() calls, nor is it in relation to concurrent rte_rand()
> + * calls.
> + *
> * @param seedval
> * The value of the seed.
> */
> -static inline void
> -rte_srand(uint64_t seedval)
> -{
> - srand48((long)seedval);
> -}
> +void
> +rte_srand(uint64_t seedval);
>
> /**
> * Get a pseudo-random value.
> *
> - * This function generates pseudo-random numbers using the linear
> - * congruential algorithm and 48-bit integer arithmetic, called twice
> - * to generate a 64-bit value.
> + * The generator is not cryptographically secure.
> + *
> + * If called from lcore threads, this function is thread-safe.
> *
> * @return
> * A pseudo-random value between 0 and (1<<64)-1.
> */
> -static inline uint64_t
> -rte_rand(void)
> -{
> - uint64_t val;
> - val = (uint64_t)lrand48();
> - val <<= 32;
> - val += (uint64_t)lrand48();
> - return val;
> -}
> +uint64_t
> +rte_rand(void);
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
> index 0670e4102..bafd23207 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -35,6 +35,7 @@ common_sources = files(
> 'rte_keepalive.c',
> 'rte_malloc.c',
> 'rte_option.c',
> + 'rte_random.c',
> 'rte_reciprocal.c',
> 'rte_service.c'
> )
> diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
> new file mode 100644
> index 000000000..288e7b8c5
> --- /dev/null
> +++ b/lib/librte_eal/common/rte_random.c
> @@ -0,0 +1,137 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2019 Ericsson AB
> + */
> +
> +#include <stdlib.h>
> +
> +#include <rte_cycles.h>
> +#include <rte_eal.h>
> +#include <rte_lcore.h>
> +#include <rte_random.h>
> +
> +struct rte_rand_state {
> + uint64_t z1;
> + uint64_t z2;
> + uint64_t z3;
> + uint64_t z4;
> + uint64_t z5;
> +} __rte_cache_aligned;
> +
> +static struct rte_rand_state rand_states[RTE_MAX_LCORE];
> +
> +static uint32_t
> +__rte_rand_lcg32(uint32_t *seed)
> +{
> + *seed = 1103515245U * *seed + 12345U;
> +
> + return *seed;
> +}
> +
> +static uint64_t
> +__rte_rand_lcg64(uint32_t *seed)
> +{
> + uint64_t low;
> + uint64_t high;
> +
> + /* A 64-bit LCG would have been much cleaner, but well-known
> + * good multiplier/increments seem hard to come by.
> + */
> +
> + low = __rte_rand_lcg32(seed);
> + high = __rte_rand_lcg32(seed);
> +
> + return low | (high << 32);
> +}
> +
> +static uint64_t
> +__rte_rand_lfsr258_gen_seed(uint32_t *seed, uint64_t min_value)
> +{
> + uint64_t res;
> +
> + res = __rte_rand_lcg64(seed);
> +
> + if (res < min_value)
> + res += min_value;
> +
> + return res;
> +}
> +
> +static void
> +__rte_srand_lfsr258(uint64_t seed, struct rte_rand_state *state)
> +{
> + uint32_t lcg_seed;
> +
> + lcg_seed = (uint32_t)(seed ^ (seed >> 32));
> +
> + state->z1 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 2UL);
> + state->z2 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 512UL);
> + state->z3 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 4096UL);
> + state->z4 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 131072UL);
> + state->z5 = __rte_rand_lfsr258_gen_seed(&lcg_seed, 8388608UL);
> +}
> +
> +void __rte_experimental
> +rte_srand(uint64_t seed)
> +{
> + unsigned int lcore_id;
> +
> + /* add lcore_id to seed to avoid having the same sequence */
> + for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++)
> + __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]);
> +}
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258_comp(uint64_t z, uint64_t a, uint64_t b, uint64_t c,
> + uint64_t d)
> +{
> + return ((z & c) << d) ^ (((z << a) ^ z) >> b);
> +}
> +
> +/* Based on L’Ecuyer, P.: Tables of maximally equidistributed combined
> + * LFSR generators.
> + */
> +
> +static __rte_always_inline uint64_t
> +__rte_rand_lfsr258(struct rte_rand_state *state)
> +{
> + state->z1 = __rte_rand_lfsr258_comp(state->z1, 1UL, 53UL,
> + 18446744073709551614UL, 10UL);
> + state->z2 = __rte_rand_lfsr258_comp(state->z2, 24UL, 50UL,
> + 18446744073709551104UL, 5UL);
> + state->z3 = __rte_rand_lfsr258_comp(state->z3, 3UL, 23UL,
> + 18446744073709547520UL, 29UL);
> + state->z4 = __rte_rand_lfsr258_comp(state->z4, 5UL, 24UL,
> + 18446744073709420544UL, 23UL);
> + state->z5 = __rte_rand_lfsr258_comp(state->z5, 3UL, 33UL,
> + 18446744073701163008UL, 8UL);
> +
> + return state->z1 ^ state->z2 ^ state->z3 ^ state->z4 ^ state->z5;
> +}
> +
> +static __rte_always_inline
> +struct rte_rand_state *__rte_rand_get_state(void)
> +{
> + unsigned int lcore_id;
> +
> + lcore_id = rte_lcore_id();
> +
> + if (unlikely(lcore_id == LCORE_ID_ANY))
> + lcore_id = rte_get_master_lcore();
> +
> + return &rand_states[lcore_id];
> +}
> +
> +uint64_t __rte_experimental
> +rte_rand(void)
Do you really want to mark this as experimental? I know it will trigger the
symbol checker with a warning if you don't, but this function already existed
previously and was accepted as part of the ABI. Given that the prototype hasn't
changed, I think you just need to accept it as a non-experimental function
> +{
> + struct rte_rand_state *state;
> +
> + state = __rte_rand_get_state();
> +
> + return __rte_rand_lfsr258(state);
> +}
> +
> +RTE_INIT(rte_rand_init)
> +{
> + rte_srand(rte_get_timer_cycles());
> +}
> diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
> index 19854ee2c..ca616c480 100644
> --- a/lib/librte_eal/freebsd/eal/Makefile
> +++ b/lib/librte_eal/freebsd/eal/Makefile
> @@ -69,6 +69,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
> index c6ac9028f..5d43310b3 100644
> --- a/lib/librte_eal/freebsd/eal/eal.c
> +++ b/lib/librte_eal/freebsd/eal/eal.c
> @@ -727,8 +727,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> /* in secondary processes, memory init may allocate additional fbarrays
> * not present in primary processes, so to avoid any potential issues,
> * initialize memzones first.
> diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
> index 6e5261152..729795a10 100644
> --- a/lib/librte_eal/linux/eal/Makefile
> +++ b/lib/librte_eal/linux/eal/Makefile
> @@ -77,6 +77,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += malloc_mp.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_keepalive.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_option.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_service.c
> +SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_random.c
> SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += rte_reciprocal.c
>
> # from arch dir
> diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
> index f7ae62d7b..c2bdf0a67 100644
> --- a/lib/librte_eal/linux/eal/eal.c
> +++ b/lib/librte_eal/linux/eal/eal.c
> @@ -1083,8 +1083,6 @@ rte_eal_init(int argc, char **argv)
> #endif
> }
>
> - rte_srand(rte_rdtsc());
> -
> if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0) {
> rte_eal_init_alert("Cannot init logging.");
> rte_errno = ENOMEM;
> diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
> index d6e375135..0d60668fa 100644
> --- a/lib/librte_eal/rte_eal_version.map
> +++ b/lib/librte_eal/rte_eal_version.map
> @@ -366,10 +366,12 @@ EXPERIMENTAL {
> rte_mp_request_async;
> rte_mp_sendmsg;
> rte_option_register;
> + rte_rand;
> rte_realloc_socket;
> rte_service_lcore_attr_get;
> rte_service_lcore_attr_reset_all;
> rte_service_may_be_active;
> rte_socket_count;
> rte_socket_id_by_idx;
> + rte_srand;
> };
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
@ 2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-22 14:49 UTC (permalink / raw)
To: Neil Horman; +Cc: Mattias Rönnblom, dev
On Mon, 22 Apr 2019 07:34:20 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> > +
> > +uint64_t __rte_experimental
> > +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
Agree with Neil. Don't mark existing functions as experimental.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 14:49 0% ` Stephen Hemminger
@ 2019-04-22 14:49 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-22 14:49 UTC (permalink / raw)
To: Neil Horman; +Cc: Mattias Rönnblom, dev
On Mon, 22 Apr 2019 07:34:20 -0400
Neil Horman <nhorman@tuxdriver.com> wrote:
> > +
> > +uint64_t __rte_experimental
> > +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
Agree with Neil. Don't mark existing functions as experimental.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
@ 2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2 siblings, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 15:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 13:34, Neil Horman wrote:
>> +uint64_t __rte_experimental
>> +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
>
I'll remove the experimental tag and move it into the 19_05 section
(without suggesting it should go into 19.05). That maneuver seems not to
trigger any build warnings/errors.
It's been a part of the API since forever, but it was never a part of
the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 15:52 3% ` Mattias Rönnblom
@ 2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 15:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 13:34, Neil Horman wrote:
>> +uint64_t __rte_experimental
>> +rte_rand(void)
> Do you really want to mark this as experimental? I know it will trigger the
> symbol checker with a warning if you don't, but this function already existed
> previously and was accepted as part of the ABI. Given that the prototype hasn't
> changed, I think you just need to accept it as a non-experimental function
>
I'll remove the experimental tag and move it into the 19_05 section
(without suggesting it should go into 19.05). That maneuver seems not to
trigger any build warnings/errors.
It's been a part of the API since forever, but it was never a part of
the ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
@ 2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 17:44 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 17:52, Mattias Rönnblom wrote:
> On 2019-04-22 13:34, Neil Horman wrote:
>
>>> +uint64_t __rte_experimental
>>> +rte_rand(void)
>> Do you really want to mark this as experimental? I know it will
>> trigger the
>> symbol checker with a warning if you don't, but this function already
>> existed
>> previously and was accepted as part of the ABI. Given that the
>> prototype hasn't
>> changed, I think you just need to accept it as a non-experimental
>> function
>>
>
> I'll remove the experimental tag and move it into the 19_05 section
> (without suggesting it should go into 19.05). That maneuver seems not to
> trigger any build warnings/errors.
>
OK, so that wasn't true. It does trigger a build error, courtesy of
buildtools/check-experimental-syms.sh.
I can't see any obvious way around it. Ideas, anyone?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
@ 2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 15:31 0% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-22 17:44 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-22 17:52, Mattias Rönnblom wrote:
> On 2019-04-22 13:34, Neil Horman wrote:
>
>>> +uint64_t __rte_experimental
>>> +rte_rand(void)
>> Do you really want to mark this as experimental? I know it will
>> trigger the
>> symbol checker with a warning if you don't, but this function already
>> existed
>> previously and was accepted as part of the ABI. Given that the
>> prototype hasn't
>> changed, I think you just need to accept it as a non-experimental
>> function
>>
>
> I'll remove the experimental tag and move it into the 19_05 section
> (without suggesting it should go into 19.05). That maneuver seems not to
> trigger any build warnings/errors.
>
OK, so that wasn't true. It does trigger a build error, courtesy of
buildtools/check-experimental-syms.sh.
I can't see any obvious way around it. Ideas, anyone?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
@ 2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 15:31 0% ` Stephen Hemminger
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-23 11:33 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> > > > +uint64_t __rte_experimental
> > > > +rte_rand(void)
> > > Do you really want to mark this as experimental? I know it will
> > > trigger the
> > > symbol checker with a warning if you don't, but this function
> > > already existed
> > > previously and was accepted as part of the ABI. Given that the
> > > prototype hasn't
> > > changed, I think you just need to accept it as a non-experimental
> > > function
> > >
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
>
No, we would have to waive it. But its pretty clear that This function has been
around forever, so I think it would be worse to demote it to an experimental
symbol. The only thing you're doing here is moving it from an inline function
(which is arguably part of the ABI, even if it never appeared as a symbol in the
ELF file), to a fully fleged symbol with a new implementation.
Neil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-23 11:33 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1351 bytes --]
On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> > > > +uint64_t __rte_experimental
> > > > +rte_rand(void)
> > > Do you really want to mark this as experimental? I know it will
> > > trigger the
> > > symbol checker with a warning if you don't, but this function
> > > already existed
> > > previously and was accepted as part of the ABI. Given that the
> > > prototype hasn't
> > > changed, I think you just need to accept it as a non-experimental
> > > function
> > >
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
>
No, we would have to waive it. But its pretty clear that This function has been
around forever, so I think it would be worse to demote it to an experimental
symbol. The only thing you're doing here is moving it from an inline function
(which is arguably part of the ABI, even if it never appeared as a symbol in the
ELF file), to a fully fleged symbol with a new implementation.
Neil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
@ 2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
` (2 more replies)
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2 siblings, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:12 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 18/04/2019 11:28, Bruce Richardson wrote:
> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>
>>> 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.
>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
I would also imagine that should be an extremely rare case, that a
bugfix would require a structure change ... perhaps for an alignment issues?
>
>>>
>>> 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
>> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>>
> No, there is never any need for two versions of the inline functions, only
> the newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever
> used. The other older versions are only used at runtime for compatilibity
> with pre-compiled apps with the older inlines.
>
>>>
>>> 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.
>> The new structure members have to be added such that the previous layout
>> is not affected. Either add at the end or use the gaps that are left
>> because of cache line alignment.
>>
> Not necessarily. There is nothing that requires the older and newer
> versions of a function to use the same structure. We can rename the
> original structure when versioning the old function, and then create a new
> structure with the original name for later recompiled code using the newest
> ABIs.
>
>>>
>>> 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
>> Yes, very clear on this.
>>
>>> 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).
>> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>>
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because
> even if it's a trivial function that takes only 10 cycles and we want to
> uninline it, the cost may double; but if it takes a burst of packets and is
> only used once/twice per burst the cost per packet should still only be a
> fraction of a cycle.
>
>>>
>>>> 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.
>> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>>
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
I completely disagree with this approach.
Anytime I have seen this done, most frequently with interpreted
languages, think multiple versions of Java and Python concurrently on a
system, it has always been a usability nightmare.
>
>>>
>>>> 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.
>>>
>> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>>
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for
> the previous version or not. Users do not want to have to go through a
> checklist for each app to see if the app uses only "compatible" APIs or
> not. Same for the distro folks, they are not going to take some libs from a
> release but not others because the ABI is broken for some but not others.
Agreed, a DPDK release is either backwards compatible or it isn't, and
to Bruce's point if it isn't, it maters less if this is for a big API
change or a small API change - the failure of the API stability
guarantee is the significant piece.
The reality is that most other system libraries provide strong
guarantees ... to date we have provided very little.
If we start saying "Yes, but except when", the exception case very
quickly becomes the general case and then we are back to the beginning
again.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:12 UTC (permalink / raw)
To: Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 18/04/2019 11:28, Bruce Richardson wrote:
> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>
>>> 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.
>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
I would also imagine that should be an extremely rare case, that a
bugfix would require a structure change ... perhaps for an alignment issues?
>
>>>
>>> 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
>> I think this can get complicated on the inline function side. The application and the DPDK library will end up having different inline functions. The changed inline function needs to be aware of 2 structure formats or the inline function needs to be duplicated (one for each version of the structure). I guess these are the workarounds we have to do.
>>
> No, there is never any need for two versions of the inline functions, only
> the newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever
> used. The other older versions are only used at runtime for compatilibity
> with pre-compiled apps with the older inlines.
>
>>>
>>> 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.
>> The new structure members have to be added such that the previous layout
>> is not affected. Either add at the end or use the gaps that are left
>> because of cache line alignment.
>>
> Not necessarily. There is nothing that requires the older and newer
> versions of a function to use the same structure. We can rename the
> original structure when versioning the old function, and then create a new
> structure with the original name for later recompiled code using the newest
> ABIs.
>
>>>
>>> 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
>> Yes, very clear on this.
>>
>>> 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).
>> A good way to think about it would be - ratio of amount of work done in the function to cost of function call.
>>
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because
> even if it's a trivial function that takes only 10 cycles and we want to
> uninline it, the cost may double; but if it takes a burst of packets and is
> only used once/twice per burst the cost per packet should still only be a
> fraction of a cycle.
>
>>>
>>>> 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.
>> I completely agree with you on trying to keep the ABI break surface small and doing due diligence when one is required. However, I think claiming 100% ABI compatibility all the time (or as frequently as other projects claim) might be tough. IMO, we need to look beyond this to solve the end user problem. May be packaging multiple LTS with distros when DPDK could not avoid breaking ABI compatibility?
>>
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
I completely disagree with this approach.
Anytime I have seen this done, most frequently with interpreted
languages, think multiple versions of Java and Python concurrently on a
system, it has always been a usability nightmare.
>
>>>
>>>> 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.
>>>
>> I think it is also important to setup the right expectations to DPDK users. i.e. DPDK will police itself better to provide ABI compatibility but occasionally it might not be possible.
>>
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for
> the previous version or not. Users do not want to have to go through a
> checklist for each app to see if the app uses only "compatible" APIs or
> not. Same for the distro folks, they are not going to take some libs from a
> release but not others because the ABI is broken for some but not others.
Agreed, a DPDK release is either backwards compatible or it isn't, and
to Bruce's point if it isn't, it maters less if this is for a big API
change or a small API change - the failure of the API stability
guarantee is the significant piece.
The reality is that most other system libraries provide strong
guarantees ... to date we have provided very little.
If we start saying "Yes, but except when", the exception case very
quickly becomes the general case and then we are back to the beginning
again.
>
> Regards,
> /Bruce
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-04-23 14:19 4% ` Ray Kinsella
2019-04-23 14:19 4% ` Ray Kinsella
2 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-04-23 14:19 UTC (permalink / raw)
To: Stephen Hemminger, Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 17/04/2019 19:51, Stephen Hemminger wrote:
> On Wed, 17 Apr 2019 17:46:34 +0000
> Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
>>> Sent: Wednesday, April 17, 2019 2:07 PM
>>> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
>>> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
>>> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
>>> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
>>> Subject: Re: [dpdk-dev] ABI and inline functions
>>>
>>>> 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
>>
>> # I think, we need consider the how fat is the function too,
>> If it is light weight, probably we need to make it inline
Well if it light weight however it is not dealing directly with packets,
probably does not matter if is not-inline?
>> # Except the forward case, In real world use case, it is not trivial make large
>> burst of packet to process it even though function prototype burst.
>> We may need to consider that
>> # For the given function if some argument is used with inline other function,
>> probably no point in making that function alone inline as the structure
>> is exposed in some other function.
>>
>>> * anything what works with single packet at a time should be inline
>>>
>>>> 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.
>>
>> IMO, We have two primary use case for DPDK
>>
>> 1) NFV kind of use case where the application needs to run on multiple platform
>> without recompiling it.
>> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
>> Controller used. For fixed appliance use case, end user care more of performance
>> than ABI compatibility as it easy to recompile the end user application vs the cost of
>> hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
>
+1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
@ 2019-04-23 14:19 4% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:19 UTC (permalink / raw)
To: Stephen Hemminger, Jerin Jacob Kollanukkaran
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 17/04/2019 19:51, Stephen Hemminger wrote:
> On Wed, 17 Apr 2019 17:46:34 +0000
> Jerin Jacob Kollanukkaran <jerinj@marvell.com> wrote:
>
>>> -----Original Message-----
>>> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
>>> Sent: Wednesday, April 17, 2019 2:07 PM
>>> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
>>> Cc: dev@dpdk.org; Stephen Hemminger <stephen@networkplumber.org>;
>>> Ananyev, Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net;
>>> Ray Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
>>> Subject: Re: [dpdk-dev] ABI and inline functions
>>>
>>>> 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
>>
>> # I think, we need consider the how fat is the function too,
>> If it is light weight, probably we need to make it inline
Well if it light weight however it is not dealing directly with packets,
probably does not matter if is not-inline?
>> # Except the forward case, In real world use case, it is not trivial make large
>> burst of packet to process it even though function prototype burst.
>> We may need to consider that
>> # For the given function if some argument is used with inline other function,
>> probably no point in making that function alone inline as the structure
>> is exposed in some other function.
>>
>>> * anything what works with single packet at a time should be inline
>>>
>>>> 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.
>>
>> IMO, We have two primary use case for DPDK
>>
>> 1) NFV kind of use case where the application needs to run on multiple platform
>> without recompiling it.
>> 2) Fixed appliance use case where embed SoC like Intel Denverton or ARM64 integrated
>> Controller used. For fixed appliance use case, end user care more of performance
>> than ABI compatibility as it easy to recompile the end user application vs the cost of
>> hitting performance impact.
>
> Nobody cares about compatiablity until they have to the first security update.
>
+1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
@ 2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:23 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
>
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Thursday, April 18, 2019 12:21 AM
>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
>> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
>> <mdr@ashroe.eu>; nd <nd@arm.com>
>> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
>>> 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.
>>>
>>> IMO, We have two primary use case for DPDK
>>>
>>> 1) NFV kind of use case where the application needs to run on multiple
>> platform
>>> without recompiling it.
>>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
>>> ARM64 integrated Controller used. For fixed appliance use case, end
>>> user care more of performance than ABI compatibility as it easy to
>>> recompile the end user application vs the cost of hitting performance impact.
>>
>> Nobody cares about compatiablity until they have to the first security update.
>
> For fixed appliance case, The update(FW update) will be a single blob which
> Include all the components. So they can back port the security fix and recompile
> the sw as needed.
>
> The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
So is there a real versus a perceived compromise happen here - that we
are compromising optimal performance in order to make API stability
happen? Do we have specific an examples that this is actually the case?
Thanks,
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-23 14:23 4% ` Ray Kinsella
@ 2019-04-23 14:23 4% ` Ray Kinsella
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-23 14:23 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
>
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Thursday, April 18, 2019 12:21 AM
>> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
>> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
>> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray Kinsella
>> <mdr@ashroe.eu>; nd <nd@arm.com>
>> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
>>> 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.
>>>
>>> IMO, We have two primary use case for DPDK
>>>
>>> 1) NFV kind of use case where the application needs to run on multiple
>> platform
>>> without recompiling it.
>>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
>>> ARM64 integrated Controller used. For fixed appliance use case, end
>>> user care more of performance than ABI compatibility as it easy to
>>> recompile the end user application vs the cost of hitting performance impact.
>>
>> Nobody cares about compatiablity until they have to the first security update.
>
> For fixed appliance case, The update(FW update) will be a single blob which
> Include all the components. So they can back port the security fix and recompile
> the sw as needed.
>
> The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP device).
So is there a real versus a perceived compromise happen here - that we
are compromising optimal performance in order to make API stability
happen? Do we have specific an examples that this is actually the case?
Thanks,
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
2 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-23 15:31 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: Neil Horman, dev
On Mon, 22 Apr 2019 19:44:39 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> >>> +uint64_t __rte_experimental
> >>> +rte_rand(void)
> >> Do you really want to mark this as experimental? I know it will
> >> trigger the
> >> symbol checker with a warning if you don't, but this function already
> >> existed
> >> previously and was accepted as part of the ABI. Given that the
> >> prototype hasn't
> >> changed, I think you just need to accept it as a non-experimental
> >> function
> >>
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
Ignore the error, the build tool is not smart enough for this kind of change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 15:31 0% ` Stephen Hemminger
@ 2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-23 15:31 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: Neil Horman, dev
On Mon, 22 Apr 2019 19:44:39 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
> On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > On 2019-04-22 13:34, Neil Horman wrote:
> >
> >>> +uint64_t __rte_experimental
> >>> +rte_rand(void)
> >> Do you really want to mark this as experimental? I know it will
> >> trigger the
> >> symbol checker with a warning if you don't, but this function already
> >> existed
> >> previously and was accepted as part of the ABI. Given that the
> >> prototype hasn't
> >> changed, I think you just need to accept it as a non-experimental
> >> function
> >>
> >
> > I'll remove the experimental tag and move it into the 19_05 section
> > (without suggesting it should go into 19.05). That maneuver seems not to
> > trigger any build warnings/errors.
> >
>
> OK, so that wasn't true. It does trigger a build error, courtesy of
> buildtools/check-experimental-syms.sh.
>
> I can't see any obvious way around it. Ideas, anyone?
Ignore the error, the build tool is not smart enough for this kind of change.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
@ 2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:13 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-23 13:33, Neil Horman wrote:
> On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function
>>>> already existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>>
> No, we would have to waive it.
I don't understand. What do you mean?
> But its pretty clear that This function has been
> around forever, so I think it would be worse to demote it to an experimental
> symbol. The only thing you're doing here is moving it from an inline function
> (which is arguably part of the ABI, even if it never appeared as a symbol in the
> ELF file), to a fully fleged symbol with a new implementation.
>
I agree it shouldn't be marked experimental. The reason for doing so was
to avoid triggering a build error.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:13 0% ` Mattias Rönnblom
@ 2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:13 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, stephen
On 2019-04-23 13:33, Neil Horman wrote:
> On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function
>>>> already existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>>
> No, we would have to waive it.
I don't understand. What do you mean?
> But its pretty clear that This function has been
> around forever, so I think it would be worse to demote it to an experimental
> symbol. The only thing you're doing here is moving it from an inline function
> (which is arguably part of the ABI, even if it never appeared as a symbol in the
> ELF file), to a fully fleged symbol with a new implementation.
>
I agree it shouldn't be marked experimental. The reason for doing so was
to avoid triggering a build error.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
@ 2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 2 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 17:31, Stephen Hemminger wrote:
> On Mon, 22 Apr 2019 19:44:39 +0200
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function already
>>>> existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>
> Ignore the error, the build tool is not smart enough for this kind of change.
>
It stops the build.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:17 0% ` Mattias Rönnblom
@ 2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-23 17:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 17:31, Stephen Hemminger wrote:
> On Mon, 22 Apr 2019 19:44:39 +0200
> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>
>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>
>>>>> +uint64_t __rte_experimental
>>>>> +rte_rand(void)
>>>> Do you really want to mark this as experimental? I know it will
>>>> trigger the
>>>> symbol checker with a warning if you don't, but this function already
>>>> existed
>>>> previously and was accepted as part of the ABI. Given that the
>>>> prototype hasn't
>>>> changed, I think you just need to accept it as a non-experimental
>>>> function
>>>>
>>>
>>> I'll remove the experimental tag and move it into the 19_05 section
>>> (without suggesting it should go into 19.05). That maneuver seems not to
>>> trigger any build warnings/errors.
>>>
>>
>> OK, so that wasn't true. It does trigger a build error, courtesy of
>> buildtools/check-experimental-syms.sh.
>>
>> I can't see any obvious way around it. Ideas, anyone?
>
> Ignore the error, the build tool is not smart enough for this kind of change.
>
It stops the build.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK Windows Community call - 18 April 2019
@ 2019-04-23 23:16 3% Ranjit Menon
2019-04-23 23:16 3% ` Ranjit Menon
0 siblings, 1 reply; 200+ results
From: Ranjit Menon @ 2019-04-23 23:16 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Harini (harini.ramakrishnan@microsoft.com)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Anand (anand.rawat@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
New interested attendees added to meeting invite for next call:
Haseeb.Gani@cavium.com
shshaikh@marvell.com
nareshkumar.pbs@broadcom.com
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives - sync up on the bus/pci and general
status
- Mellanox agrees bus/pci port should be our next target
- Intel has latest bus/pci updates available in windows draft repo
c. Any other business
Minutes:
-------
- Removing rte_panic() calls in EAL (and other libraries)
- Some functions that call rte_panic() are defined as 'void' return.
- will need to modify these functions - which breaks ABI.
- If we're doing this it would require deprecation notice in 19.05.
- Group discussion on removal of rte panics void returns.
- Might need another definition for fatal error codes
- Why? The application layer will assess whether something is fatal
- Better to return what the error is and let the application take the
decision on whether or not it’s a fatal error.
- Advice is to use current error codes that is close enough to the error
seen.
- Use a matching a core id error – we should pass back an int-return and
allow the app to decide what action to take.
- Thomas says Arnon Warshavsky (arnon@qwilt.com) was working on removing
rte panics last year (eal: replace rte_panic instances to return an
error value).
- Check the list of what APIs need to change and get the list out now to
the community in 19.05.
- This woudl be a pre-announcement message to the mailing list – this is
sent as a patch in 19.05, explaining what will be changed in which files.
- Offline discussion with Arnon: see mailing list for detail.
- What other changes do we need to do in EAL to make upstreaming easier?
- Open source libraries to support common code (BSD licenses).
- May need a better wrapper on Linux files to use for windows.
- Some of them (eg: pthreads) not supported in windows
- so we did macro substitutions to use Windows threads.
- Wrappers could be used more widely.
- Need to work out how to do this more widely.
- Please send your ideas for a solution to the mailing list to seek
comments (RFC).
- We need to identify the blockers we’re aware of at the moment
- Perhaps, TSC is one.
- Send interesting topics for the community to work on.
- Is the bus/pci code available?
- Ask is to move the bus/pci code over to the latest branch (intel).
- Intel/Microsoft currently working to tidy up the branches & names on
windows draft repo.
- Any new code for the tree?
- Microsoft is trying to add new code to existing UIO driver
- This will be available on windows draft repo (18.08 branch)
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Windows Community call - 18 April 2019
2019-04-23 23:16 3% [dpdk-dev] DPDK Windows Community call - 18 April 2019 Ranjit Menon
@ 2019-04-23 23:16 3% ` Ranjit Menon
0 siblings, 0 replies; 200+ results
From: Ranjit Menon @ 2019-04-23 23:16 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Harini (harini.ramakrishnan@microsoft.com)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Anand (anand.rawat@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
New interested attendees added to meeting invite for next call:
Haseeb.Gani@cavium.com
shshaikh@marvell.com
nareshkumar.pbs@broadcom.com
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives - sync up on the bus/pci and general
status
- Mellanox agrees bus/pci port should be our next target
- Intel has latest bus/pci updates available in windows draft repo
c. Any other business
Minutes:
-------
- Removing rte_panic() calls in EAL (and other libraries)
- Some functions that call rte_panic() are defined as 'void' return.
- will need to modify these functions - which breaks ABI.
- If we're doing this it would require deprecation notice in 19.05.
- Group discussion on removal of rte panics void returns.
- Might need another definition for fatal error codes
- Why? The application layer will assess whether something is fatal
- Better to return what the error is and let the application take the
decision on whether or not it’s a fatal error.
- Advice is to use current error codes that is close enough to the error
seen.
- Use a matching a core id error – we should pass back an int-return and
allow the app to decide what action to take.
- Thomas says Arnon Warshavsky (arnon@qwilt.com) was working on removing
rte panics last year (eal: replace rte_panic instances to return an
error value).
- Check the list of what APIs need to change and get the list out now to
the community in 19.05.
- This woudl be a pre-announcement message to the mailing list – this is
sent as a patch in 19.05, explaining what will be changed in which files.
- Offline discussion with Arnon: see mailing list for detail.
- What other changes do we need to do in EAL to make upstreaming easier?
- Open source libraries to support common code (BSD licenses).
- May need a better wrapper on Linux files to use for windows.
- Some of them (eg: pthreads) not supported in windows
- so we did macro substitutions to use Windows threads.
- Wrappers could be used more widely.
- Need to work out how to do this more widely.
- Please send your ideas for a solution to the mailing list to seek
comments (RFC).
- We need to identify the blockers we’re aware of at the moment
- Perhaps, TSC is one.
- Send interesting topics for the community to work on.
- Is the bus/pci code available?
- Ask is to move the bus/pci code over to the latest branch (intel).
- Intel/Microsoft currently working to tidy up the branches & names on
windows draft repo.
- Any new code for the tree?
- Microsoft is trying to add new code to existing UIO driver
- This will be available on windows draft repo (18.08 branch)
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
@ 2019-04-24 8:18 20% Peng Huang
2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Peng Huang @ 2019-04-24 8:18 UTC (permalink / raw)
To: maintainer; +Cc: dev, peng.huang
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 20%]
* [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
@ 2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Peng Huang @ 2019-04-24 8:18 UTC (permalink / raw)
To: maintainer; +Cc: dev, peng.huang
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 20%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
2 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:08 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, nd, 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.
> > If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
>
Agree on the requirement.
> > >
> > > 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
> > I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >
> No, there is never any need for two versions of the inline functions, only the
> newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever used.
> The other older versions are only used at runtime for compatilibity with pre-
> compiled apps with the older inlines.
>
Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
> > >
> > > 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.
> > The new structure members have to be added such that the previous
> > layout is not affected. Either add at the end or use the gaps that are
> > left because of cache line alignment.
> >
> Not necessarily. There is nothing that requires the older and newer versions
> of a function to use the same structure. We can rename the original structure
> when versioning the old function, and then create a new structure with the
> original name for later recompiled code using the newest ABIs.
>
Agree, assuming only the app is using the inline functions.
> > >
> > > 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
> > Yes, very clear on this.
> >
> > > 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).
> > A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because even
> if it's a trivial function that takes only 10 cycles and we want to uninline it,
> the cost may double; but if it takes a burst of packets and is only used
> once/twice per burst the cost per packet should still only be a fraction of a
> cycle.
>
> > >
> > > > 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.
> > I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
>
> > >
> > > > 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.
> > >
> > I think it is also important to setup the right expectations to DPDK users. i.e.
> DPDK will police itself better to provide ABI compatibility but occasionally it
> might not be possible.
> >
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for the
> previous version or not. Users do not want to have to go through a checklist
> for each app to see if the app uses only "compatible" APIs or not. Same for
For the releases where the ABI is broken, would not such a list help the users?
> the distro folks, they are not going to take some libs from a release but not
> others because the ABI is broken for some but not others.
Yes, this is not an option, it becomes a DPDK release of its own 😊.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:08 7% ` Honnappa Nagarahalli
@ 2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:08 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas,
Ray Kinsella, nd, 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.
> > If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >
>
> If the application wants the bugfix, then yes. However, if the app is
> unaffected by the bug, then it should have the option of updating DPDK
> without a recompile.
>
Agree on the requirement.
> > >
> > > 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
> > I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >
> No, there is never any need for two versions of the inline functions, only the
> newest version is needed. This is because in the case of a newly compiled
> application only the newest version of the non-inline functions is ever used.
> The other older versions are only used at runtime for compatilibity with pre-
> compiled apps with the older inlines.
>
Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
> > >
> > > 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.
> > The new structure members have to be added such that the previous
> > layout is not affected. Either add at the end or use the gaps that are
> > left because of cache line alignment.
> >
> Not necessarily. There is nothing that requires the older and newer versions
> of a function to use the same structure. We can rename the original structure
> when versioning the old function, and then create a new structure with the
> original name for later recompiled code using the newest ABIs.
>
Agree, assuming only the app is using the inline functions.
> > >
> > > 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
> > Yes, very clear on this.
> >
> > > 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).
> > A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >
>
> Yes, I would tend to agree in general. The other thing is the frequency of
> calls, and - as already stated - whether it takes a burst of not. Because even
> if it's a trivial function that takes only 10 cycles and we want to uninline it,
> the cost may double; but if it takes a burst of packets and is only used
> once/twice per burst the cost per packet should still only be a fraction of a
> cycle.
>
> > >
> > > > 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.
> > I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >
> Having multiple LTS's per distro would be nice, but it's putting a lot more
> work on the distro folks, I think.
>
> > >
> > > > 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.
> > >
> > I think it is also important to setup the right expectations to DPDK users. i.e.
> DPDK will police itself better to provide ABI compatibility but occasionally it
> might not be possible.
> >
> The trouble here is that a DPDK release, as a product is either backward
> compatible or not. Either a user can take it as a drop-in replacement for the
> previous version or not. Users do not want to have to go through a checklist
> for each app to see if the app uses only "compatible" APIs or not. Same for
For the releases where the ABI is broken, would not such a list help the users?
> the distro folks, they are not going to take some libs from a release but not
> others because the ABI is broken for some but not others.
Yes, this is not an option, it becomes a DPDK release of its own 😊.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
@ 2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:15 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd, nd
> On 18/04/2019 11:28, Bruce Richardson wrote:
> > On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>
> >>> 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.
> >> If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >>
> >
> > If the application wants the bugfix, then yes. However, if the app is
> > unaffected by the bug, then it should have the option of updating DPDK
> > without a recompile.
>
> I would also imagine that should be an extremely rare case, that a bugfix
> would require a structure change ... perhaps for an alignment issues?
>
> >
> >>>
> >>> 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
> >> I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >>
> > No, there is never any need for two versions of the inline functions,
> > only the newest version is needed. This is because in the case of a
> > newly compiled application only the newest version of the non-inline
> > functions is ever used. The other older versions are only used at
> > runtime for compatilibity with pre-compiled apps with the older inlines.
> >
> >>>
> >>> 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.
> >> The new structure members have to be added such that the previous
> >> layout is not affected. Either add at the end or use the gaps that
> >> are left because of cache line alignment.
> >>
> > Not necessarily. There is nothing that requires the older and newer
> > versions of a function to use the same structure. We can rename the
> > original structure when versioning the old function, and then create a
> > new structure with the original name for later recompiled code using
> > the newest ABIs.
> >
> >>>
> >>> 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
> >> Yes, very clear on this.
> >>
> >>> 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).
> >> A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >>
> >
> > Yes, I would tend to agree in general. The other thing is the
> > frequency of calls, and - as already stated - whether it takes a burst
> > of not. Because even if it's a trivial function that takes only 10
> > cycles and we want to uninline it, the cost may double; but if it
> > takes a burst of packets and is only used once/twice per burst the
> > cost per packet should still only be a fraction of a cycle.
> >
> >>>
> >>>> 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.
> >> I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >>
> > Having multiple LTS's per distro would be nice, but it's putting a lot
> > more work on the distro folks, I think.
>
> I completely disagree with this approach.
> Anytime I have seen this done, most frequently with interpreted languages,
> think multiple versions of Java and Python concurrently on a system, it has
> always been a usability nightmare.
>
>
> >
> >>>
> >>>> 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.
> >>>
> >> I think it is also important to setup the right expectations to DPDK users.
> i.e. DPDK will police itself better to provide ABI compatibility but occasionally
> it might not be possible.
> >>
> > The trouble here is that a DPDK release, as a product is either
> > backward compatible or not. Either a user can take it as a drop-in
> > replacement for the previous version or not. Users do not want to have
> > to go through a checklist for each app to see if the app uses only
> > "compatible" APIs or not. Same for the distro folks, they are not
> > going to take some libs from a release but not others because the ABI is
> broken for some but not others.
>
> Agreed, a DPDK release is either backwards compatible or it isn't, and to
> Bruce's point if it isn't, it maters less if this is for a big API change or a small
> API change - the failure of the API stability guarantee is the significant piece.
>
> The reality is that most other system libraries provide strong guarantees ... to
> date we have provided very little.
It would be good to look libraries that provide inline functions and ABI compatibility to better understand the methods used.
>
> If we start saying "Yes, but except when", the exception case very quickly
> becomes the general case and then we are back to the beginning again.
>
> >
> > Regards,
> > /Bruce
> >
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:15 7% ` Honnappa Nagarahalli
@ 2019-04-24 5:15 7% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-04-24 5:15 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd, nd
> On 18/04/2019 11:28, Bruce Richardson wrote:
> > On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>
> >>> 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.
> >> If there is a bug fix which requires the structure to change, the application
> would need to recompile. I guess you are talking about a scenario when
> nothing changed in the inline function/variables.
> >>
> >
> > If the application wants the bugfix, then yes. However, if the app is
> > unaffected by the bug, then it should have the option of updating DPDK
> > without a recompile.
>
> I would also imagine that should be an extremely rare case, that a bugfix
> would require a structure change ... perhaps for an alignment issues?
>
> >
> >>>
> >>> 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
> >> I think this can get complicated on the inline function side. The application
> and the DPDK library will end up having different inline functions. The
> changed inline function needs to be aware of 2 structure formats or the inline
> function needs to be duplicated (one for each version of the structure). I
> guess these are the workarounds we have to do.
> >>
> > No, there is never any need for two versions of the inline functions,
> > only the newest version is needed. This is because in the case of a
> > newly compiled application only the newest version of the non-inline
> > functions is ever used. The other older versions are only used at
> > runtime for compatilibity with pre-compiled apps with the older inlines.
> >
> >>>
> >>> 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.
> >> The new structure members have to be added such that the previous
> >> layout is not affected. Either add at the end or use the gaps that
> >> are left because of cache line alignment.
> >>
> > Not necessarily. There is nothing that requires the older and newer
> > versions of a function to use the same structure. We can rename the
> > original structure when versioning the old function, and then create a
> > new structure with the original name for later recompiled code using
> > the newest ABIs.
> >
> >>>
> >>> 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
> >> Yes, very clear on this.
> >>
> >>> 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).
> >> A good way to think about it would be - ratio of amount of work done in
> the function to cost of function call.
> >>
> >
> > Yes, I would tend to agree in general. The other thing is the
> > frequency of calls, and - as already stated - whether it takes a burst
> > of not. Because even if it's a trivial function that takes only 10
> > cycles and we want to uninline it, the cost may double; but if it
> > takes a burst of packets and is only used once/twice per burst the
> > cost per packet should still only be a fraction of a cycle.
> >
> >>>
> >>>> 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.
> >> I completely agree with you on trying to keep the ABI break surface small
> and doing due diligence when one is required. However, I think claiming 100%
> ABI compatibility all the time (or as frequently as other projects claim) might
> be tough. IMO, we need to look beyond this to solve the end user problem.
> May be packaging multiple LTS with distros when DPDK could not avoid
> breaking ABI compatibility?
> >>
> > Having multiple LTS's per distro would be nice, but it's putting a lot
> > more work on the distro folks, I think.
>
> I completely disagree with this approach.
> Anytime I have seen this done, most frequently with interpreted languages,
> think multiple versions of Java and Python concurrently on a system, it has
> always been a usability nightmare.
>
>
> >
> >>>
> >>>> 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.
> >>>
> >> I think it is also important to setup the right expectations to DPDK users.
> i.e. DPDK will police itself better to provide ABI compatibility but occasionally
> it might not be possible.
> >>
> > The trouble here is that a DPDK release, as a product is either
> > backward compatible or not. Either a user can take it as a drop-in
> > replacement for the previous version or not. Users do not want to have
> > to go through a checklist for each app to see if the app uses only
> > "compatible" APIs or not. Same for the distro folks, they are not
> > going to take some libs from a release but not others because the ABI is
> broken for some but not others.
>
> Agreed, a DPDK release is either backwards compatible or it isn't, and to
> Bruce's point if it isn't, it maters less if this is for a big API change or a small
> API change - the failure of the API stability guarantee is the significant piece.
>
> The reality is that most other system libraries provide strong guarantees ... to
> date we have provided very little.
It would be good to look libraries that provide inline functions and ABI compatibility to better understand the methods used.
>
> If we start saying "Yes, but except when", the exception case very quickly
> becomes the general case and then we are back to the beginning again.
>
> >
> > Regards,
> > /Bruce
> >
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
@ 2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
1 sibling, 1 reply; 200+ results
From: Mattias Rönnblom @ 2019-04-24 7:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 19:17, Mattias Rönnblom wrote:
> On 2019-04-23 17:31, Stephen Hemminger wrote:
>> On Mon, 22 Apr 2019 19:44:39 +0200
>> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>>
>>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>>>> +uint64_t __rte_experimental
>>>>>> +rte_rand(void)
>>>>> Do you really want to mark this as experimental? I know it will
>>>>> trigger the
>>>>> symbol checker with a warning if you don't, but this function already
>>>>> existed
>>>>> previously and was accepted as part of the ABI. Given that the
>>>>> prototype hasn't
>>>>> changed, I think you just need to accept it as a non-experimental
>>>>> function
>>>>
>>>> I'll remove the experimental tag and move it into the 19_05 section
>>>> (without suggesting it should go into 19.05). That maneuver seems
>>>> not to
>>>> trigger any build warnings/errors.
>>>
>>> OK, so that wasn't true. It does trigger a build error, courtesy of
>>> buildtools/check-experimental-syms.sh.
>>>
>>> I can't see any obvious way around it. Ideas, anyone?
>>
>> Ignore the error, the build tool is not smart enough for this kind of
>> change.
>>
>
> It stops the build.
OK, so what was the way of a successful build was not the
check-experimental-syms.sh script, but my incompetence. I had listed
rte_rand in both the 19_05 section, and the EXPERIMENTAL section.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-24 7:52 0% ` Mattias Rönnblom
@ 2019-04-24 7:52 0% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-04-24 7:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Neil Horman, dev
On 2019-04-23 19:17, Mattias Rönnblom wrote:
> On 2019-04-23 17:31, Stephen Hemminger wrote:
>> On Mon, 22 Apr 2019 19:44:39 +0200
>> Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:
>>
>>> On 2019-04-22 17:52, Mattias Rönnblom wrote:
>>>> On 2019-04-22 13:34, Neil Horman wrote:
>>>>>> +uint64_t __rte_experimental
>>>>>> +rte_rand(void)
>>>>> Do you really want to mark this as experimental? I know it will
>>>>> trigger the
>>>>> symbol checker with a warning if you don't, but this function already
>>>>> existed
>>>>> previously and was accepted as part of the ABI. Given that the
>>>>> prototype hasn't
>>>>> changed, I think you just need to accept it as a non-experimental
>>>>> function
>>>>
>>>> I'll remove the experimental tag and move it into the 19_05 section
>>>> (without suggesting it should go into 19.05). That maneuver seems
>>>> not to
>>>> trigger any build warnings/errors.
>>>
>>> OK, so that wasn't true. It does trigger a build error, courtesy of
>>> buildtools/check-experimental-syms.sh.
>>>
>>> I can't see any obvious way around it. Ideas, anyone?
>>
>> Ignore the error, the build tool is not smart enough for this kind of
>> change.
>>
>
> It stops the build.
OK, so what was the way of a successful build was not the
check-experimental-syms.sh script, but my incompetence. I had listed
rte_rand in both the 19_05 section, and the EXPERIMENTAL section.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
@ 2019-04-24 15:11 22% Peng Huang
2019-04-24 12:08 4% ` Neil Horman
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Peng Huang @ 2019-04-24 15:11 UTC (permalink / raw)
To: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu; +Cc: dev, peng.huang, stable
The new default-taget "linux" is introduced in v19.05-rc1
but not exist in before release such as v19.02 which have
default-target "linuxapp", there is no compatibility report
when run validate-abi.sh to check ABI compatibility between
v19.05-rc1 and v19.02, changed default-target from "linux"
to "linuxapp" in validate-abi.sh
Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
Cc: stable@dpdk.org
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 22%]
* [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:32 4% ` Bruce Richardson
@ 2019-04-24 15:11 22% ` Peng Huang
2 siblings, 0 replies; 200+ results
From: Peng Huang @ 2019-04-24 15:11 UTC (permalink / raw)
To: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu; +Cc: dev, peng.huang, stable
The new default-taget "linux" is introduced in v19.05-rc1
but not exist in before release such as v19.02 which have
default-target "linuxapp", there is no compatibility report
when run validate-abi.sh to check ABI compatibility between
v19.05-rc1 and v19.02, changed default-target from "linux"
to "linuxapp" in validate-abi.sh
Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
Cc: stable@dpdk.org
Signed-off-by: Peng Huang <peng.huang@intel.com>
---
devtools/validate-abi.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 54df2e4..138436d 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linux-gcc
+default_target=x86_64-native-linuxapp-gcc
# trap on error
err_report() {
--
1.8.3.1
^ permalink raw reply [relevance 22%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
@ 2019-04-24 8:49 4% ` Bruce Richardson
2019-04-24 8:49 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 8:49 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 24, 2019 at 05:08:46AM +0000, Honnappa Nagarahalli wrote:
> > > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> > wrote:
> > > > > Hello,
<snip>
> > > >
> > > > 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
> > > I think this can get complicated on the inline function side. The application
> > and the DPDK library will end up having different inline functions. The
> > changed inline function needs to be aware of 2 structure formats or the inline
> > function needs to be duplicated (one for each version of the structure). I
> > guess these are the workarounds we have to do.
> > >
> > No, there is never any need for two versions of the inline functions, only the
> > newest version is needed. This is because in the case of a newly compiled
> > application only the newest version of the non-inline functions is ever used.
> > The other older versions are only used at runtime for compatilibity with pre-
> > compiled apps with the older inlines.
> >
> Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
>
Ok, if the inline function is used both in DPDK libs and apps, then indeed
we have a slightly more complex problem. I was mostly assuming the inlines
were for app use only, but you are right that we have internally used ones
also. However, I expect this only makes the problem a little harder rather
than impossible - we would need two versions of the inline function,
however, only one needs to be exposed publically.
Really, the main upshot is that we need to reduce use of inline functions
except where absolutely necessary, and then hide structures as much as
possible. I don't see anyone disagreeing with that goal. :-)
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 8:49 4% ` Bruce Richardson
@ 2019-04-24 8:49 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 8:49 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, Ray Kinsella, nd
On Wed, Apr 24, 2019 at 05:08:46AM +0000, Honnappa Nagarahalli wrote:
> > > > On Wed, Apr 17, 2019 at 05:12:43AM +0000, Honnappa Nagarahalli
> > wrote:
> > > > > Hello,
<snip>
> > > >
> > > > 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
> > > I think this can get complicated on the inline function side. The application
> > and the DPDK library will end up having different inline functions. The
> > changed inline function needs to be aware of 2 structure formats or the inline
> > function needs to be duplicated (one for each version of the structure). I
> > guess these are the workarounds we have to do.
> > >
> > No, there is never any need for two versions of the inline functions, only the
> > newest version is needed. This is because in the case of a newly compiled
> > application only the newest version of the non-inline functions is ever used.
> > The other older versions are only used at runtime for compatilibity with pre-
> > compiled apps with the older inlines.
> >
> Since the inline function is used in the application and the DPDK (say a library), we have 2 copies of the same inline function in the final binary (1 with the application and 2nd one behind DPDK non-inline functions). When the DPDK non-inline functions are versioned, the older version of the functions have to support the old structures for the old application to work with the new DPDK. i.e. both copies of the inline function have to be the same.
>
Ok, if the inline function is used both in DPDK libs and apps, then indeed
we have a slightly more complex problem. I was mostly assuming the inlines
were for app use only, but you are right that we have internally used ones
also. However, I expect this only makes the problem a little harder rather
than impossible - we would need two versions of the inline function,
however, only one needs to be exposed publically.
Really, the main upshot is that we need to reduce use of inline functions
except where absolutely necessary, and then hide structures as much as
possible. I don't see anyone disagreeing with that goal. :-)
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
2019-04-24 8:18 20% ` Peng Huang
@ 2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 8:56 4% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 8:56 UTC (permalink / raw)
To: Peng Huang; +Cc: maintainer, dev
On Wed, Apr 24, 2019 at 08:18:09AM +0000, Peng Huang wrote:
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
I think you need a fuller description of the problem here - that although
"linux" is the new target name, we still need to use "linuxapp" for testing
historical versions.
Fixes tag also needed.
/Bruce
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh
2019-04-24 8:56 4% ` Bruce Richardson
@ 2019-04-24 8:56 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 8:56 UTC (permalink / raw)
To: Peng Huang; +Cc: maintainer, dev
On Wed, Apr 24, 2019 at 08:18:09AM +0000, Peng Huang wrote:
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
I think you need a fuller description of the problem here - that although
"linux" is the new target name, we still need to use "linuxapp" for testing
historical versions.
Fixes tag also needed.
/Bruce
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
@ 2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 11:08 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>
>
> On 18/04/2019 11:28, Bruce Richardson wrote:
>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>
>>>> 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.
>>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>>
>>
>> If the application wants the bugfix, then yes. However, if the app is
>> unaffected by the bug, then it should have the option of updating DPDK
>> without a recompile.
>
> I would also imagine that should be an extremely rare case, that a
> bugfix would require a structure change ... perhaps for an alignment issues?
Multiprocess threading issues is one case i've had to do that more than
once.
<snip>
>
> The reality is that most other system libraries provide strong
> guarantees ... to date we have provided very little.
>
To our credit, the libraries you're likely referring to aren't trying to
reimplement the Linux kernel :) I don't think we do these API/ABI breaks
just because we like doing them - DPDK is complex, and getting
everything right the first time *and* allowing for future evolution is
not a trivial undertaking.
To me, part of the problem is that DPDK is an "everything and the
kitchen sink" kind of library where there is a bunch of drivers, a whole
quasi-OS layer of dealing with hardware in a cross-platform manner, a
separate memory management system, a bunch of libraries such as hash/lpm
tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
library" would concentrate on doing one thing well. DPDK, on the other
hand, tries to do *everything* well. The sheer breadth of DPDK's scope
is, i think, contributing to the breakages. If you keep 99% of your
libraries stable between version, but there's a small ABI tweak in an
LPM library, the entire DPDK stability gets invalidated.
Perhaps limiting DPDK's scope would help with this as well.
>
>>
>> Regards,
>> /Bruce
>>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 11:08 8% ` Burakov, Anatoly
@ 2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 11:08 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>
>
> On 18/04/2019 11:28, Bruce Richardson wrote:
>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>
>>>> 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.
>>> If there is a bug fix which requires the structure to change, the application would need to recompile. I guess you are talking about a scenario when nothing changed in the inline function/variables.
>>>
>>
>> If the application wants the bugfix, then yes. However, if the app is
>> unaffected by the bug, then it should have the option of updating DPDK
>> without a recompile.
>
> I would also imagine that should be an extremely rare case, that a
> bugfix would require a structure change ... perhaps for an alignment issues?
Multiprocess threading issues is one case i've had to do that more than
once.
<snip>
>
> The reality is that most other system libraries provide strong
> guarantees ... to date we have provided very little.
>
To our credit, the libraries you're likely referring to aren't trying to
reimplement the Linux kernel :) I don't think we do these API/ABI breaks
just because we like doing them - DPDK is complex, and getting
everything right the first time *and* allowing for future evolution is
not a trivial undertaking.
To me, part of the problem is that DPDK is an "everything and the
kitchen sink" kind of library where there is a bunch of drivers, a whole
quasi-OS layer of dealing with hardware in a cross-platform manner, a
separate memory management system, a bunch of libraries such as hash/lpm
tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
library" would concentrate on doing one thing well. DPDK, on the other
hand, tries to do *everything* well. The sheer breadth of DPDK's scope
is, i think, contributing to the breakages. If you keep 99% of your
libraries stable between version, but there's a small ABI tweak in an
LPM library, the entire DPDK stability gets invalidated.
Perhaps limiting DPDK's scope would help with this as well.
>
>>
>> Regards,
>> /Bruce
>>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
@ 2019-04-24 11:37 0% ` Neil Horman
2019-04-24 11:37 0% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Neil Horman @ 2019-04-24 11:37 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
On Tue, Apr 23, 2019 at 07:13:24PM +0200, Mattias Rönnblom wrote:
> On 2019-04-23 13:33, Neil Horman wrote:
> > On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> > > On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > > > On 2019-04-22 13:34, Neil Horman wrote:
> > > >
> > > > > > +uint64_t __rte_experimental
> > > > > > +rte_rand(void)
> > > > > Do you really want to mark this as experimental? I know it will
> > > > > trigger the
> > > > > symbol checker with a warning if you don't, but this function
> > > > > already existed
> > > > > previously and was accepted as part of the ABI. Given that the
> > > > > prototype hasn't
> > > > > changed, I think you just need to accept it as a non-experimental
> > > > > function
> > > > >
> > > >
> > > > I'll remove the experimental tag and move it into the 19_05 section
> > > > (without suggesting it should go into 19.05). That maneuver seems not to
> > > > trigger any build warnings/errors.
> > > >
> > >
> > > OK, so that wasn't true. It does trigger a build error, courtesy of
> > > buildtools/check-experimental-syms.sh.
> > >
> > > I can't see any obvious way around it. Ideas, anyone?
> > >
> > No, we would have to waive it.
>
> I don't understand. What do you mean?
>
I mean we have to work around the error, understanding that its not really
experimental. My first suggestion would be to make a commit with the symbol as
experimental, than add a new commit moving it into the proper section of the
version map
> > But its pretty clear that This function has been
> > around forever, so I think it would be worse to demote it to an experimental
> > symbol. The only thing you're doing here is moving it from an inline function
> > (which is arguably part of the ABI, even if it never appeared as a symbol in the
> > ELF file), to a fully fleged symbol with a new implementation.
> >
>
> I agree it shouldn't be marked experimental. The reason for doing so was to
> avoid triggering a build error.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR
2019-04-24 11:37 0% ` Neil Horman
@ 2019-04-24 11:37 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-04-24 11:37 UTC (permalink / raw)
To: Mattias Rönnblom; +Cc: dev, stephen
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 1993 bytes --]
On Tue, Apr 23, 2019 at 07:13:24PM +0200, Mattias Rönnblom wrote:
> On 2019-04-23 13:33, Neil Horman wrote:
> > On Mon, Apr 22, 2019 at 07:44:39PM +0200, Mattias Rönnblom wrote:
> > > On 2019-04-22 17:52, Mattias Rönnblom wrote:
> > > > On 2019-04-22 13:34, Neil Horman wrote:
> > > >
> > > > > > +uint64_t __rte_experimental
> > > > > > +rte_rand(void)
> > > > > Do you really want to mark this as experimental? I know it will
> > > > > trigger the
> > > > > symbol checker with a warning if you don't, but this function
> > > > > already existed
> > > > > previously and was accepted as part of the ABI. Given that the
> > > > > prototype hasn't
> > > > > changed, I think you just need to accept it as a non-experimental
> > > > > function
> > > > >
> > > >
> > > > I'll remove the experimental tag and move it into the 19_05 section
> > > > (without suggesting it should go into 19.05). That maneuver seems not to
> > > > trigger any build warnings/errors.
> > > >
> > >
> > > OK, so that wasn't true. It does trigger a build error, courtesy of
> > > buildtools/check-experimental-syms.sh.
> > >
> > > I can't see any obvious way around it. Ideas, anyone?
> > >
> > No, we would have to waive it.
>
> I don't understand. What do you mean?
>
I mean we have to work around the error, understanding that its not really
experimental. My first suggestion would be to make a commit with the symbol as
experimental, than add a new commit moving it into the proper section of the
version map
> > But its pretty clear that This function has been
> > around forever, so I think it would be worse to demote it to an experimental
> > symbol. The only thing you're doing here is moving it from an inline function
> > (which is arguably part of the ABI, even if it never appeared as a symbol in the
> > ELF file), to a fully fleged symbol with a new implementation.
> >
>
> I agree it shouldn't be marked experimental. The reason for doing so was to
> avoid triggering a build error.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
@ 2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:08 4% ` Neil Horman
2019-05-01 23:47 4% ` Thomas Monjalon
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2 siblings, 2 replies; 200+ results
From: Neil Horman @ 2019-04-24 12:08 UTC (permalink / raw)
To: Peng Huang; +Cc: qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:08 4% ` Neil Horman
@ 2019-04-24 12:08 4% ` Neil Horman
2019-05-01 23:47 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-04-24 12:08 UTC (permalink / raw)
To: Peng Huang; +Cc: qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
> ---
> devtools/validate-abi.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 54df2e4..138436d 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -9,7 +9,7 @@ set -e
> abicheck=abi-compliance-checker
> abidump=abi-dumper
> default_dst=abi-check
> -default_target=x86_64-native-linux-gcc
> +default_target=x86_64-native-linuxapp-gcc
>
> # trap on error
> err_report() {
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
@ 2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Ray Kinsella @ 2019-04-24 12:22 UTC (permalink / raw)
To: Burakov, Anatoly, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24/04/2019 12:08, Burakov, Anatoly wrote:
> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>
>>
>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>
>>>>> 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.
>>>> If there is a bug fix which requires the structure to change, the
>>>> application would need to recompile. I guess you are talking about a
>>>> scenario when nothing changed in the inline function/variables.
>>>>
>>>
>>> If the application wants the bugfix, then yes. However, if the app is
>>> unaffected by the bug, then it should have the option of updating DPDK
>>> without a recompile.
>>
>> I would also imagine that should be an extremely rare case, that a
>> bugfix would require a structure change ... perhaps for an alignment
>> issues?
>
> Multiprocess threading issues is one case i've had to do that more than
> once.
Another reason to dislike multi process I guess.
>
> <snip>
>
>
>>
>> The reality is that most other system libraries provide strong
>> guarantees ... to date we have provided very little.
>>
>
> To our credit, the libraries you're likely referring to aren't trying to
> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> just because we like doing them - DPDK is complex, and getting
> everything right the first time *and* allowing for future evolution is
> not a trivial undertaking.
>
>
> To me, part of the problem is that DPDK is an "everything and the
> kitchen sink" kind of library where there is a bunch of drivers, a whole
> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> separate memory management system, a bunch of libraries such as hash/lpm
> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> library" would concentrate on doing one thing well. DPDK, on the other
> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> is, i think, contributing to the breakages. If you keep 99% of your
> libraries stable between version, but there's a small ABI tweak in an
> LPM library, the entire DPDK stability gets invalidated.
Well I guess DPDK is no more complex than Java or .NET Framework in that
respect, as these also feature OS-layers, memory management systems,
application frameworks, primitives etc but do manage to give their
consumers strong guarantee's on API stability. Clearly ABI stability has
a no meaning when you always being JIT compiled.
I understand that doing everything right the first time, allowing for
future evolution, while keep ABI/APIs relatively stable is a tough ask.
I would propose that API's marked as "experimental" be given greater
freedom to change to give time of API's to bake, so they don't need to
be always "right first time", that there is wriggle room for these.
I would also propose more use of ABI Versioning to enable evolution of
DPDK while preserving backward compatibility.
>
> Perhaps limiting DPDK's scope would help with this as well.
I agree.
>
>>
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:22 9% ` Ray Kinsella
@ 2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-30 8:52 9% ` Thomas Monjalon
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-04-24 12:22 UTC (permalink / raw)
To: Burakov, Anatoly, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24/04/2019 12:08, Burakov, Anatoly wrote:
> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>
>>
>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>
>>>>> 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.
>>>> If there is a bug fix which requires the structure to change, the
>>>> application would need to recompile. I guess you are talking about a
>>>> scenario when nothing changed in the inline function/variables.
>>>>
>>>
>>> If the application wants the bugfix, then yes. However, if the app is
>>> unaffected by the bug, then it should have the option of updating DPDK
>>> without a recompile.
>>
>> I would also imagine that should be an extremely rare case, that a
>> bugfix would require a structure change ... perhaps for an alignment
>> issues?
>
> Multiprocess threading issues is one case i've had to do that more than
> once.
Another reason to dislike multi process I guess.
>
> <snip>
>
>
>>
>> The reality is that most other system libraries provide strong
>> guarantees ... to date we have provided very little.
>>
>
> To our credit, the libraries you're likely referring to aren't trying to
> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> just because we like doing them - DPDK is complex, and getting
> everything right the first time *and* allowing for future evolution is
> not a trivial undertaking.
>
>
> To me, part of the problem is that DPDK is an "everything and the
> kitchen sink" kind of library where there is a bunch of drivers, a whole
> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> separate memory management system, a bunch of libraries such as hash/lpm
> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> library" would concentrate on doing one thing well. DPDK, on the other
> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> is, i think, contributing to the breakages. If you keep 99% of your
> libraries stable between version, but there's a small ABI tweak in an
> LPM library, the entire DPDK stability gets invalidated.
Well I guess DPDK is no more complex than Java or .NET Framework in that
respect, as these also feature OS-layers, memory management systems,
application frameworks, primitives etc but do manage to give their
consumers strong guarantee's on API stability. Clearly ABI stability has
a no meaning when you always being JIT compiled.
I understand that doing everything right the first time, allowing for
future evolution, while keep ABI/APIs relatively stable is a tough ask.
I would propose that API's marked as "experimental" be given greater
freedom to change to give time of API's to bake, so they don't need to
be always "right first time", that there is wriggle room for these.
I would also propose more use of ABI Versioning to enable evolution of
DPDK while preserving backward compatibility.
>
> Perhaps limiting DPDK's scope would help with this as well.
I agree.
>
>>
>>>
>>> Regards,
>>> /Bruce
>>>
>>
>
>
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
@ 2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-04-24 12:32 UTC (permalink / raw)
To: Peng Huang; +Cc: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:32 4% ` Bruce Richardson
@ 2019-04-24 12:32 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-04-24 12:32 UTC (permalink / raw)
To: Peng Huang; +Cc: nhorman, qi.z.zhang, qiming.yang, wenzhuo.lu, dev, stable
On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> The new default-taget "linux" is introduced in v19.05-rc1
> but not exist in before release such as v19.02 which have
> default-target "linuxapp", there is no compatibility report
> when run validate-abi.sh to check ABI compatibility between
> v19.05-rc1 and v19.02, changed default-target from "linux"
> to "linuxapp" in validate-abi.sh
>
> Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> Cc: stable@dpdk.org
>
> Signed-off-by: Peng Huang <peng.huang@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
@ 2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-30 8:52 9% ` Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 12:54 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
>
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
>> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>>
>>>
>>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>>
>>>>>> 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.
>>>>> If there is a bug fix which requires the structure to change, the
>>>>> application would need to recompile. I guess you are talking about a
>>>>> scenario when nothing changed in the inline function/variables.
>>>>>
>>>>
>>>> If the application wants the bugfix, then yes. However, if the app is
>>>> unaffected by the bug, then it should have the option of updating DPDK
>>>> without a recompile.
>>>
>>> I would also imagine that should be an extremely rare case, that a
>>> bugfix would require a structure change ... perhaps for an alignment
>>> issues?
>>
>> Multiprocess threading issues is one case i've had to do that more than
>> once.
>
> Another reason to dislike multi process I guess.
>
>>
>> <snip>
>>
>>
>>>
>>> The reality is that most other system libraries provide strong
>>> guarantees ... to date we have provided very little.
>>>
>>
>> To our credit, the libraries you're likely referring to aren't trying to
>> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
>> just because we like doing them - DPDK is complex, and getting
>> everything right the first time *and* allowing for future evolution is
>> not a trivial undertaking.
>>
>>
>> To me, part of the problem is that DPDK is an "everything and the
>> kitchen sink" kind of library where there is a bunch of drivers, a whole
>> quasi-OS layer of dealing with hardware in a cross-platform manner, a
>> separate memory management system, a bunch of libraries such as hash/lpm
>> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
>> library" would concentrate on doing one thing well. DPDK, on the other
>> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
>> is, i think, contributing to the breakages. If you keep 99% of your
>> libraries stable between version, but there's a small ABI tweak in an
>> LPM library, the entire DPDK stability gets invalidated.
>
> Well I guess DPDK is no more complex than Java or .NET Framework in that
> respect, as these also feature OS-layers, memory management systems,
> application frameworks, primitives etc but do manage to give their
> consumers strong guarantee's on API stability. Clearly ABI stability has
> a no meaning when you always being JIT compiled.
I was basing my response on your earlier comparisons of DPDK to
GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
then these frameworks generally go through much more rigorous
development/design cycle than DPDK does - DPDK's API design process is
pretty ad-hoc, while both Java and .NET have various kinds of procedures
by which things get into the standard library. If we're prepared to do
that - i'm all for it. What we can't have is stability *and* keep the
same approach to design/development that we have now.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-04-24 12:54 UTC (permalink / raw)
To: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli
Cc: dev, Stephen Hemminger, Ananyev, Konstantin, thomas, nd
On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
>
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
>> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
>>>
>>>
>>> On 18/04/2019 11:28, Bruce Richardson wrote:
>>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
>>>>>>
>>>>>> 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.
>>>>> If there is a bug fix which requires the structure to change, the
>>>>> application would need to recompile. I guess you are talking about a
>>>>> scenario when nothing changed in the inline function/variables.
>>>>>
>>>>
>>>> If the application wants the bugfix, then yes. However, if the app is
>>>> unaffected by the bug, then it should have the option of updating DPDK
>>>> without a recompile.
>>>
>>> I would also imagine that should be an extremely rare case, that a
>>> bugfix would require a structure change ... perhaps for an alignment
>>> issues?
>>
>> Multiprocess threading issues is one case i've had to do that more than
>> once.
>
> Another reason to dislike multi process I guess.
>
>>
>> <snip>
>>
>>
>>>
>>> The reality is that most other system libraries provide strong
>>> guarantees ... to date we have provided very little.
>>>
>>
>> To our credit, the libraries you're likely referring to aren't trying to
>> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
>> just because we like doing them - DPDK is complex, and getting
>> everything right the first time *and* allowing for future evolution is
>> not a trivial undertaking.
>>
>>
>> To me, part of the problem is that DPDK is an "everything and the
>> kitchen sink" kind of library where there is a bunch of drivers, a whole
>> quasi-OS layer of dealing with hardware in a cross-platform manner, a
>> separate memory management system, a bunch of libraries such as hash/lpm
>> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
>> library" would concentrate on doing one thing well. DPDK, on the other
>> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
>> is, i think, contributing to the breakages. If you keep 99% of your
>> libraries stable between version, but there's a small ABI tweak in an
>> LPM library, the entire DPDK stability gets invalidated.
>
> Well I guess DPDK is no more complex than Java or .NET Framework in that
> respect, as these also feature OS-layers, memory management systems,
> application frameworks, primitives etc but do manage to give their
> consumers strong guarantee's on API stability. Clearly ABI stability has
> a no meaning when you always being JIT compiled.
I was basing my response on your earlier comparisons of DPDK to
GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
then these frameworks generally go through much more rigorous
development/design cycle than DPDK does - DPDK's API design process is
pretty ad-hoc, while both Java and .NET have various kinds of procedures
by which things get into the standard library. If we're prepared to do
that - i'm all for it. What we can't have is stability *and* keep the
same approach to design/development that we have now.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-24 15:44 4% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-04-24 15:44 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli, dev,
Ananyev, Konstantin, thomas, nd
On Wed, 24 Apr 2019 13:54:51 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
> >
> > On 24/04/2019 12:08, Burakov, Anatoly wrote:
> >> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
> >>>
> >>>
> >>> On 18/04/2019 11:28, Bruce Richardson wrote:
> >>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>>>>
> >>>>>> 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.
> >>>>> If there is a bug fix which requires the structure to change, the
> >>>>> application would need to recompile. I guess you are talking about a
> >>>>> scenario when nothing changed in the inline function/variables.
> >>>>>
> >>>>
> >>>> If the application wants the bugfix, then yes. However, if the app is
> >>>> unaffected by the bug, then it should have the option of updating DPDK
> >>>> without a recompile.
> >>>
> >>> I would also imagine that should be an extremely rare case, that a
> >>> bugfix would require a structure change ... perhaps for an alignment
> >>> issues?
> >>
> >> Multiprocess threading issues is one case i've had to do that more than
> >> once.
> >
> > Another reason to dislike multi process I guess.
> >
> >>
> >> <snip>
> >>
> >>
> >>>
> >>> The reality is that most other system libraries provide strong
> >>> guarantees ... to date we have provided very little.
> >>>
> >>
> >> To our credit, the libraries you're likely referring to aren't trying to
> >> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> >> just because we like doing them - DPDK is complex, and getting
> >> everything right the first time *and* allowing for future evolution is
> >> not a trivial undertaking.
> >>
> >>
> >> To me, part of the problem is that DPDK is an "everything and the
> >> kitchen sink" kind of library where there is a bunch of drivers, a whole
> >> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> >> separate memory management system, a bunch of libraries such as hash/lpm
> >> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> >> library" would concentrate on doing one thing well. DPDK, on the other
> >> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> >> is, i think, contributing to the breakages. If you keep 99% of your
> >> libraries stable between version, but there's a small ABI tweak in an
> >> LPM library, the entire DPDK stability gets invalidated.
> >
> > Well I guess DPDK is no more complex than Java or .NET Framework in that
> > respect, as these also feature OS-layers, memory management systems,
> > application frameworks, primitives etc but do manage to give their
> > consumers strong guarantee's on API stability. Clearly ABI stability has
> > a no meaning when you always being JIT compiled.
>
> I was basing my response on your earlier comparisons of DPDK to
> GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
> then these frameworks generally go through much more rigorous
> development/design cycle than DPDK does - DPDK's API design process is
> pretty ad-hoc, while both Java and .NET have various kinds of procedures
> by which things get into the standard library. If we're prepared to do
> that - i'm all for it. What we can't have is stability *and* keep the
> same approach to design/development that we have now.
>
Lets step back a bit. I think some of the basic business rules which
go back to the "Innovators dilemma" are that it is NOT a good idea
to pay too much attention to existing customers. Instead, it is important
to pay attention to the need of the potential customers that could
use your product.
In this case, my argument is that it is important for the DPDK project
to pay more attention to the reasons that new users
do not want to use the project; and existing users do not want to
upgrade. This problem has been repeatedly expressed as:
"DPDK is not stable". The project needs to address that concern
even if it means a 1% drop in performance. Surely that 1% can be
made up by improving other places. Even using link-time-optimization
can give 2 to 5 % back.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 15:44 4% ` Stephen Hemminger
@ 2019-04-24 15:44 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-24 15:44 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Bruce Richardson, Honnappa Nagarahalli, dev,
Ananyev, Konstantin, thomas, nd
On Wed, 24 Apr 2019 13:54:51 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 24-Apr-19 1:22 PM, Ray Kinsella wrote:
> >
> > On 24/04/2019 12:08, Burakov, Anatoly wrote:
> >> On 23-Apr-19 3:12 PM, Ray Kinsella wrote:
> >>>
> >>>
> >>> On 18/04/2019 11:28, Bruce Richardson wrote:
> >>>> On Thu, Apr 18, 2019 at 04:34:53AM +0000, Honnappa Nagarahalli wrote:
> >>>>>>
> >>>>>> 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.
> >>>>> If there is a bug fix which requires the structure to change, the
> >>>>> application would need to recompile. I guess you are talking about a
> >>>>> scenario when nothing changed in the inline function/variables.
> >>>>>
> >>>>
> >>>> If the application wants the bugfix, then yes. However, if the app is
> >>>> unaffected by the bug, then it should have the option of updating DPDK
> >>>> without a recompile.
> >>>
> >>> I would also imagine that should be an extremely rare case, that a
> >>> bugfix would require a structure change ... perhaps for an alignment
> >>> issues?
> >>
> >> Multiprocess threading issues is one case i've had to do that more than
> >> once.
> >
> > Another reason to dislike multi process I guess.
> >
> >>
> >> <snip>
> >>
> >>
> >>>
> >>> The reality is that most other system libraries provide strong
> >>> guarantees ... to date we have provided very little.
> >>>
> >>
> >> To our credit, the libraries you're likely referring to aren't trying to
> >> reimplement the Linux kernel :) I don't think we do these API/ABI breaks
> >> just because we like doing them - DPDK is complex, and getting
> >> everything right the first time *and* allowing for future evolution is
> >> not a trivial undertaking.
> >>
> >>
> >> To me, part of the problem is that DPDK is an "everything and the
> >> kitchen sink" kind of library where there is a bunch of drivers, a whole
> >> quasi-OS layer of dealing with hardware in a cross-platform manner, a
> >> separate memory management system, a bunch of libraries such as hash/lpm
> >> tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> >> library" would concentrate on doing one thing well. DPDK, on the other
> >> hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> >> is, i think, contributing to the breakages. If you keep 99% of your
> >> libraries stable between version, but there's a small ABI tweak in an
> >> LPM library, the entire DPDK stability gets invalidated.
> >
> > Well I guess DPDK is no more complex than Java or .NET Framework in that
> > respect, as these also feature OS-layers, memory management systems,
> > application frameworks, primitives etc but do manage to give their
> > consumers strong guarantee's on API stability. Clearly ABI stability has
> > a no meaning when you always being JIT compiled.
>
> I was basing my response on your earlier comparisons of DPDK to
> GStreamer :) Comparing it to .NET Framework is perhaps a better fit, but
> then these frameworks generally go through much more rigorous
> development/design cycle than DPDK does - DPDK's API design process is
> pretty ad-hoc, while both Java and .NET have various kinds of procedures
> by which things get into the standard library. If we're prepared to do
> that - i'm all for it. What we can't have is stability *and* keep the
> same approach to design/development that we have now.
>
Lets step back a bit. I think some of the basic business rules which
go back to the "Innovators dilemma" are that it is NOT a good idea
to pay too much attention to existing customers. Instead, it is important
to pay attention to the need of the potential customers that could
use your product.
In this case, my argument is that it is important for the DPDK project
to pay more attention to the reasons that new users
do not want to use the project; and existing users do not want to
upgrade. This problem has been repeatedly expressed as:
"DPDK is not stable". The project needs to address that concern
even if it means a 1% drop in performance. Surely that 1% can be
made up by improving other places. Even using link-time-optimization
can give 2 to 5 % back.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:23 4% ` Ray Kinsella
@ 2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
1 sibling, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-24 18:38 UTC (permalink / raw)
To: Ray Kinsella, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, April 23, 2019 7:54 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; nd <nd@arm.com>
> Subject: Re: [EXT] Re: [dpdk-dev] ABI and inline functions
>
>
>
> On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
> >
> >> -----Original Message-----
> >> From: Stephen Hemminger <stephen@networkplumber.org>
> >> Sent: Thursday, April 18, 2019 12:21 AM
> >> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> >> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa
> >> Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev,
> >> Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray
> >> Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> >> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> >>> 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.
> >>>
> >>> IMO, We have two primary use case for DPDK
> >>>
> >>> 1) NFV kind of use case where the application needs to run on multiple
> >> platform
> >>> without recompiling it.
> >>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
> >>> ARM64 integrated Controller used. For fixed appliance use case, end
> >>> user care more of performance than ABI compatibility as it easy to
> >>> recompile the end user application vs the cost of hitting performance
> impact.
> >>
> >> Nobody cares about compatiablity until they have to the first security update.
> >
> > For fixed appliance case, The update(FW update) will be a single blob
> > which Include all the components. So they can back port the security
> > fix and recompile the sw as needed.
> >
> > The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP
> device).
>
> So is there a real versus a perceived compromise happen here - that we are
> compromising optimal performance in order to make API stability happen? Do
> we have specific an examples that this is actually the case?
The arm64 integrated SoC would functions as PCIE EP mode as well.
That would means that you will have x86/arm64 server machine and
Integrated NIC controller SoC connected to server over PCIE. The usecase for
this to have packet processing offload from server to EP device to save server cycles.
Where EP device will be treated as FW and internally it runs DPDK as HW
Abstraction library for FW.
>
> Thanks,
>
> Ray K
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: ABI and inline functions
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
@ 2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-04-24 18:38 UTC (permalink / raw)
To: Ray Kinsella, Stephen Hemminger
Cc: Bruce Richardson, Honnappa Nagarahalli, dev, Ananyev, Konstantin,
thomas, nd
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Tuesday, April 23, 2019 7:54 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Stephen Hemminger
> <stephen@networkplumber.org>
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; nd <nd@arm.com>
> Subject: Re: [EXT] Re: [dpdk-dev] ABI and inline functions
>
>
>
> On 18/04/2019 06:56, Jerin Jacob Kollanukkaran wrote:
> >
> >> -----Original Message-----
> >> From: Stephen Hemminger <stephen@networkplumber.org>
> >> Sent: Thursday, April 18, 2019 12:21 AM
> >> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> >> Cc: Bruce Richardson <bruce.richardson@intel.com>; Honnappa
> >> Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; Ananyev,
> >> Konstantin <konstantin.ananyev@intel.com>; thomas@monjalon.net; Ray
> >> Kinsella <mdr@ashroe.eu>; nd <nd@arm.com>
> >> Subject: [EXT] Re: [dpdk-dev] ABI and inline functions
> >>> 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.
> >>>
> >>> IMO, We have two primary use case for DPDK
> >>>
> >>> 1) NFV kind of use case where the application needs to run on multiple
> >> platform
> >>> without recompiling it.
> >>> 2) Fixed appliance use case where embed SoC like Intel Denverton or
> >>> ARM64 integrated Controller used. For fixed appliance use case, end
> >>> user care more of performance than ABI compatibility as it easy to
> >>> recompile the end user application vs the cost of hitting performance
> impact.
> >>
> >> Nobody cares about compatiablity until they have to the first security update.
> >
> > For fixed appliance case, The update(FW update) will be a single blob
> > which Include all the components. So they can back port the security
> > fix and recompile the sw as needed.
> >
> > The very similar category is DPDK running in smart NICs(Runs as FW in PCIe EP
> device).
>
> So is there a real versus a perceived compromise happen here - that we are
> compromising optimal performance in order to make API stability happen? Do
> we have specific an examples that this is actually the case?
The arm64 integrated SoC would functions as PCIE EP mode as well.
That would means that you will have x86/arm64 server machine and
Integrated NIC controller SoC connected to server over PCIE. The usecase for
this to have packet processing offload from server to EP device to save server cycles.
Where EP device will be treated as FW and internally it runs DPDK as HW
Abstraction library for FW.
>
> Thanks,
>
> Ray K
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
@ 2019-04-26 15:14 1% John McNamara
2019-04-26 15:14 1% ` John McNamara
0 siblings, 1 reply; 200+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell
2019-04-26 15:14 1% [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
@ 2019-04-26 15:14 1% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-04-26 15:14 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix spelling errors in the guide docs.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/compressdevs/overview.rst | 2 +-
doc/guides/contributing/patches.rst | 2 +-
doc/guides/cryptodevs/aesni_mb.rst | 2 +-
doc/guides/cryptodevs/overview.rst | 2 +-
doc/guides/cryptodevs/scheduler.rst | 2 +-
doc/guides/eventdevs/opdl.rst | 2 +-
doc/guides/eventdevs/sw.rst | 4 ++--
doc/guides/howto/lm_bond_virtio_sriov.rst | 2 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 ++--
doc/guides/howto/rte_flow.rst | 6 ++---
doc/guides/howto/telemetry.rst | 2 +-
.../howto/virtio_user_as_exceptional_path.rst | 8 +++----
doc/guides/nics/af_packet.rst | 4 ++--
doc/guides/nics/atlantic.rst | 2 +-
doc/guides/nics/cxgbe.rst | 4 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/dpaa2.rst | 2 +-
doc/guides/nics/ena.rst | 2 +-
doc/guides/nics/enetc.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/i40e.rst | 2 +-
doc/guides/nics/ixgbe.rst | 4 ++--
doc/guides/nics/kni.rst | 2 +-
doc/guides/nics/mlx4.rst | 2 +-
doc/guides/nics/mlx5.rst | 4 ++--
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/netvsc.rst | 2 +-
doc/guides/nics/nfb.rst | 2 +-
doc/guides/nics/nfp.rst | 4 ++--
doc/guides/nics/sfc_efx.rst | 14 +++++------
doc/guides/nics/szedata2.rst | 2 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/platform/dpaa.rst | 4 ++--
doc/guides/platform/dpaa2.rst | 4 ++--
doc/guides/prog_guide/bbdev.rst | 4 ++--
doc/guides/prog_guide/compressdev.rst | 6 ++---
doc/guides/prog_guide/cryptodev_lib.rst | 12 +++++-----
doc/guides/prog_guide/dev_kit_build_system.rst | 2 +-
doc/guides/prog_guide/efd_lib.rst | 2 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
.../prog_guide/event_ethernet_rx_adapter.rst | 6 ++---
doc/guides/prog_guide/eventdev.rst | 6 ++---
doc/guides/prog_guide/ipsec_lib.rst | 16 ++++++-------
doc/guides/prog_guide/kernel_nic_interface.rst | 2 +-
doc/guides/prog_guide/metrics_lib.rst | 2 +-
doc/guides/prog_guide/multi_proc_support.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 ++--
doc/guides/prog_guide/rte_flow.rst | 8 +++----
doc/guides/prog_guide/rte_security.rst | 20 ++++++++--------
doc/guides/prog_guide/traffic_management.rst | 2 +-
doc/guides/prog_guide/vhost_lib.rst | 2 +-
doc/guides/rawdevs/ifpga_rawdev.rst | 2 +-
doc/guides/rel_notes/known_issues.rst | 8 +++----
doc/guides/rel_notes/release_17_11.rst | 10 ++++----
doc/guides/sample_app_ug/bbdev_app.rst | 4 ++--
doc/guides/sample_app_ug/eventdev_pipeline.rst | 2 +-
doc/guides/sample_app_ug/intro.rst | 2 +-
doc/guides/sample_app_ug/ip_pipeline.rst | 4 ++--
doc/guides/sample_app_ug/ipsec_secgw.rst | 8 +++----
doc/guides/sample_app_ug/performance_thread.rst | 4 ++--
doc/guides/sample_app_ug/qos_metering.rst | 2 +-
doc/guides/sample_app_ug/test_pipeline.rst | 2 +-
doc/guides/sample_app_ug/vhost.rst | 4 ++--
doc/guides/sample_app_ug/vhost_scsi.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 10 ++++----
doc/guides/testpmd_app_ug/run_app.rst | 10 ++++----
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 28 +++++++++++-----------
doc/guides/tools/cryptoperf.rst | 22 ++++++++---------
doc/guides/tools/proc_info.rst | 6 ++---
doc/guides/tools/testbbdev.rst | 2 +-
71 files changed, 170 insertions(+), 170 deletions(-)
diff --git a/doc/guides/compressdevs/overview.rst b/doc/guides/compressdevs/overview.rst
index 70bbe82..809e4e6 100644
--- a/doc/guides/compressdevs/overview.rst
+++ b/doc/guides/compressdevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
without making any modifications to it (no compression done).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means PMD supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index d8404e6..3b2b174 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -8,7 +8,7 @@ Contributing Code to DPDK
This document outlines the guidelines for submitting code to DPDK.
-The DPDK development process is modelled (loosely) on the Linux Kernel development model so it is worth reading the
+The DPDK development process is modeled (loosely) on the Linux Kernel development model so it is worth reading the
Linux kernel guide on submitting patches:
`How to Get Your Change Into the Linux Kernel <https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_.
The rationale for many of the DPDK guidelines is explained in greater detail in the kernel guidelines.
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 8915201..1eff2b0 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -129,7 +129,7 @@ Extra notes
For AES Counter mode (AES-CTR), the library supports two different sizes for Initialization
Vector (IV):
-* 12 bytes: used mainly for IPSec, as it requires 12 bytes from the user, which internally
+* 12 bytes: used mainly for IPsec, as it requires 12 bytes from the user, which internally
are appended the counter block (4 bytes), which is set to 1 for the first block
(no padding required from the user)
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index 12f342b..a972c79 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -18,7 +18,7 @@ Supported Feature Flags
being the operation in-place (input address = output address).
- "OOP SGL In SGL Out" feature flag stands for
- "Out-of-place Scatter-gather list Input, Scatter-gater list Output",
+ "Out-of-place Scatter-gather list Input, Scatter-gather list Output",
which means pmd supports different scatter-gather styled input and output buffers
(i.e. both can consists of multiple segments).
diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index a754a27..7004ca4 100644
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -165,7 +165,7 @@ operation:
For pure small packet size (64 bytes) traffic however the multi-core mode is not
an optimal solution, as it doesn't give significant per-core performance improvement.
For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
- For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+ For large packets (1.5 kbytes) scheduler shows linear scaling in performance
up to eight cores.
Each worker uses its own slave cryptodev. Only software cryptodevs
are supported. Only the same type of cryptodevs should be used concurrently.
diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst
index 0262a33..979f6cd 100644
--- a/doc/guides/eventdevs/opdl.rst
+++ b/doc/guides/eventdevs/opdl.rst
@@ -8,7 +8,7 @@ The OPDL (Ordered Packet Distribution Library) eventdev is a specific\
implementation of the eventdev API. It is particularly suited to packet\
processing workloads that have high throughput and low latency requirements.\
All packets follow the same path through the device. The order in which\
-packets follow is determinted by the order in which queues are set up.\
+packets follow is determined by the order in which queues are set up.\
Events are left on the ring until they are transmitted. As a result packets\
do not go out of order
diff --git a/doc/guides/eventdevs/sw.rst b/doc/guides/eventdevs/sw.rst
index afdcad7..04c8b03 100644
--- a/doc/guides/eventdevs/sw.rst
+++ b/doc/guides/eventdevs/sw.rst
@@ -70,7 +70,7 @@ Credit Quanta
The credit quanta is the number of credits that a port will fetch at a time from
the instance's credit pool. Higher numbers will cause less overhead in the
atomic credit fetch code, however it also reduces the overall number of credits
-in the system faster. A balanced number (eg 32) ensures that only small numbers
+in the system faster. A balanced number (e.g. 32) ensures that only small numbers
of credits are pre-allocated at a time, while also mitigating performance impact
of the atomics.
@@ -100,7 +100,7 @@ feature would be significant.
~~~~~~~~~~~~~~~~~~
The software eventdev does not support creating queues that handle all types of
-traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
+traffic. An eventdev with this capability allows enqueuing Atomic, Ordered and
Parallel traffic to the same queue, but scheduling each of them appropriately.
The reason to not allow Atomic, Ordered and Parallel event types in the
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index ee8ccda..07563b3 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -328,7 +328,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
testpmd> show bonding config 2
testpmd> port attach 0000:00:04.0
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 6ebc10f..ecb7832 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -243,7 +243,7 @@ On host_server_2: Terminal 1
.. code-block:: console
- testomd> show port info all
+ testpmd> show port info all
testpmd> show port stats all
Virtio traffic is seen at P0 and P1.
@@ -338,7 +338,7 @@ reset_vf_on_212_131.sh
#!/bin/sh
# This script is run on the host 10.237.212.131 to reset SRIOV
- # BDF for Ninatic NIC is 0000:06:00.0
+ # BDF for Niantic NIC is 0000:06:00.0
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
echo 0 > /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
cat /sys/bus/pci/devices/0000\:06\:00.0/max_vfs
diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst
index 3dcda6c..e197376 100644
--- a/doc/guides/howto/rte_flow.rst
+++ b/doc/guides/howto/rte_flow.rst
@@ -23,7 +23,7 @@ In this example we will create a simple rule that drops packets whose IPv4
destination equals 192.168.3.2. This code is equivalent to the following
testpmd command (wrapped for clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst is 192.168.3.2 / end actions drop / end
Code
@@ -118,7 +118,7 @@ a mask.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan /
+ testpmd> flow create 0 ingress pattern eth / vlan /
ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 /
end actions drop / end
@@ -219,7 +219,7 @@ In this example we will create a rule that routes all vlan id 123 to queue 3.
This code is equivalent to the following testpmd command (wrapped for
clarity)::
- tpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
+ testpmd> flow create 0 ingress pattern eth / vlan vid spec 123 /
end actions queue index 3 / end
Code
diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst
index 00f8f7a..e10804d 100644
--- a/doc/guides/howto/telemetry.rst
+++ b/doc/guides/howto/telemetry.rst
@@ -18,7 +18,7 @@ which acts as the client.
In DPDK, applications are used to initialize the ``telemetry``. To view incoming
traffic on featured ports, the application should be run first (ie. after ports
are configured). Once the application is running, the service assurance agent
-(for example the collectd plugin) should be run to begin querying the API.
+(for example the CollectD plugin) should be run to begin querying the API.
A client connects their Service Assurance application to the DPDK application
via a UNIX socket. Once a connection is established, a client can send JSON
diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst
index 4910c12..ec021af 100644
--- a/doc/guides/howto/virtio_user_as_exceptional_path.rst
+++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2016 Intel Corporation.
-.. _virtio_user_as_excpetional_path:
+.. _virtio_user_as_exceptional_path:
Virtio_user as Exceptional Path
===============================
@@ -22,7 +22,7 @@ solution is very promising in:
* Features
vhost-net is born to be a networking solution, which has lots of networking
- related featuers, like multi queue, tso, multi-seg mbuf, etc.
+ related features, like multi queue, tso, multi-seg mbuf, etc.
* Performance
@@ -38,7 +38,7 @@ in :numref:`figure_virtio_user_as_exceptional_path`.
.. figure:: img/virtio_user_as_exceptional_path.*
- Overview of a DPDK app using virtio-user as excpetional path
+ Overview of a DPDK app using virtio-user as exceptional path
Sample Usage
@@ -75,7 +75,7 @@ compiling the kernel and those kernel modules should be inserted.
* ``queues``
- Number of multi-queues. Each qeueue will be served by a kthread. For example:
+ Number of multi-queues. Each queue will be served by a kthread. For example:
.. code-block:: console
diff --git a/doc/guides/nics/af_packet.rst b/doc/guides/nics/af_packet.rst
index 1260bb2..efd6f1c 100644
--- a/doc/guides/nics/af_packet.rst
+++ b/doc/guides/nics/af_packet.rst
@@ -13,13 +13,13 @@ PACKET_MMAP, which provides a mmap'ed ring buffer, shared between user space
and kernel, that's used to send and receive packets. This helps reducing system
calls and the copies needed between user space and Kernel.
-The PACKET_FANOUT_HASH behaviour of AF_PACKET is used for frame reception.
+The PACKET_FANOUT_HASH behavior of AF_PACKET is used for frame reception.
Options and inherent limitations
--------------------------------
The following options can be provided to set up an af_packet port in DPDK.
-Some of these, in turn, will be used to configure the PAKET_MMAP settings.
+Some of these, in turn, will be used to configure the PACKET_MMAP settings.
* ``iface`` - name of the Kernel interface to attach to (required);
* ``qpairs`` - number of Rx and Tx queues (optional, default 1);
diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst
index 22f2410..3f3f294 100644
--- a/doc/guides/nics/atlantic.rst
+++ b/doc/guides/nics/atlantic.rst
@@ -18,7 +18,7 @@ Supported features
- Port statistics
- RSS (Receive Side Scaling)
- Checksum offload
-- Jumbo Frame upto 16K
+- Jumbo Frame up to 16K
- MACSEC offload
Experimental API features
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index f3e6115..7a893cc 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -126,7 +126,7 @@ enabling debugging options may affect system performance.
- ``CONFIG_RTE_LIBRTE_CXGBE_TPUT`` (default **y**)
- Toggle behaviour to prefer Throughput or Latency.
+ Toggle behavior to prefer Throughput or Latency.
Runtime Options
~~~~~~~~~~~~~~~
@@ -140,7 +140,7 @@ be passed as part of EAL arguments. For example,
- ``keep_ovlan`` (default **0**)
- Toggle behaviour to keep/strip outer VLAN in Q-in-Q packets. If
+ Toggle behavior to keep/strip outer VLAN in Q-in-Q packets. If
enabled, the outer VLAN tag is preserved in Q-in-Q packets. Otherwise,
the outer VLAN tag is stripped in Q-in-Q packets.
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index fb7bc7d..2243a4a 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -251,7 +251,7 @@ state during application initialization:
automatically be assigned from the these high perf PUSH queues. Any queue
configuration beyond that will be standard Rx queues. The application can
choose to change their number if HW portals are limited.
- The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ The valid values are from '0' to '4'. The values shall be set to '0' if the
application want to use eventdev with DPAA device.
diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst
index d74d8f8..b3b7678 100644
--- a/doc/guides/nics/dpaa2.rst
+++ b/doc/guides/nics/dpaa2.rst
@@ -379,7 +379,7 @@ active -- Ethernet, crypto, compression, etc.
DPBP based Mempool driver
~~~~~~~~~~~~~~~~~~~~~~~~~
-The DPBP driver is bound to a DPBP objects and provides sevices to
+The DPBP driver is bound to a DPBP objects and provides services to
create a hardware offloaded packet buffer mempool.
DPAA2 NIC Driver
diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst
index 80da4b6..d44f3cd 100644
--- a/doc/guides/nics/ena.rst
+++ b/doc/guides/nics/ena.rst
@@ -189,7 +189,7 @@ Prerequisites
reduces the latency of the packets by pushing the header directly through
the PCI to the device, before the DMA is even triggered. For proper work
kernel PCI driver must support write combining (WC). In mainline version of
- ``igb_uio`` (in DPDK repo) it must be enabled by loding module with
+ ``igb_uio`` (in DPDK repo) it must be enabled by loading module with
``wc_activate=1`` flag (example below). However, mainline's vfio-pci
driver in kernel doesn't have WC support yet (planed to be added).
If vfio-pci used user should be either turn off ENAv2 (to avoid performance
diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst
index 2620460..3c896ee 100644
--- a/doc/guides/nics/enetc.rst
+++ b/doc/guides/nics/enetc.rst
@@ -76,7 +76,7 @@ Supported ENETC SoCs
Prerequisites
~~~~~~~~~~~~~
-There are three main pre-requisities for executing ENETC PMD on a ENETC
+There are three main pre-requisites for executing ENETC PMD on a ENETC
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 726a69e..cdb55e0 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -224,7 +224,7 @@ the use of SR-IOV.
passthrough devices do not require libvirt, port profiles, and VM-FEX.
-.. _enic-genic-flow-api:
+.. _enic-generic-flow-api:
Generic Flow API support
------------------------
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index c5bf322..d57ddc2 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -495,7 +495,7 @@ Supports adding traffic mirroring rules.
Inline crypto
-------------
-Supports inline crypto processing (eg. inline IPsec). See Security library and PMD documentation for more details.
+Supports inline crypto processing (e.g. inline IPsec). See Security library and PMD documentation for more details.
* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_SECURITY``.
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index 9680a92..2e9ec79 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -580,7 +580,7 @@ bandwidth setting.
TC TX scheduling mode setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There're 2 TX scheduling modes for TCs, round robin and strict priority mode.
+There are 2 TX scheduling modes for TCs, round robin and strict priority mode.
If a TC is set to strict priority mode, it can consume unlimited bandwidth.
It means if APP has set the max bandwidth for that TC, it comes to no
effect.
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index 1c294b0..975143f 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -203,8 +203,8 @@ as a workaround.
X550 does not support legacy interrupt mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Desccription
-^^^^^^^^^^^^
+Description
+^^^^^^^^^^^
X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy
interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states
that the Interrupt Status bit is not implemented. The errata is the item #22
diff --git a/doc/guides/nics/kni.rst b/doc/guides/nics/kni.rst
index a66c595..602a06b 100644
--- a/doc/guides/nics/kni.rst
+++ b/doc/guides/nics/kni.rst
@@ -65,7 +65,7 @@ backend device by default.
PMD arguments
-------------
-``no_request_thread``, by default PMD creates a phtread for each KNI interface
+``no_request_thread``, by default PMD creates a pthread for each KNI interface
to handle Linux network interface control commands, like ``ifconfig kni0 up``
With ``no_request_thread`` option, pthread is not created and control commands
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index aaf1907..f6d7a16 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -83,7 +83,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx4**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx4**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 5fa6b62..af1e408 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -168,7 +168,7 @@ Limitations
- must specify the VXLAN item with tunnel outer parameters.
- must specify the tunnel outer VNI in the VXLAN item.
- must specify the tunnel outer remote (destination) UDP port in the VXLAN item.
- - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed.
+ - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interface, wildcards not allowed.
- must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed.
- must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule.
@@ -216,7 +216,7 @@ These options can be modified in the ``.config`` file.
- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
- Embed static flavour of the dependencies **libibverbs** and **libmlx5**
+ Embed static flavor of the dependencies **libibverbs** and **libmlx5**
in the PMD shared library or the executable static binary.
- ``CONFIG_RTE_LIBRTE_MLX5_DEBUG`` (default **n**)
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 09e2f2a..bacc013 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -91,7 +91,7 @@ Limitations
chance to start in a sane state.
- MUSDK architecture does not support changing configuration in run time.
- All nessesary configurations should be done before first dev_start().
+ All necessary configurations should be done before first dev_start().
- RX queue start/stop is not supported.
diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst
index 87fabf5..6dbb9a5 100644
--- a/doc/guides/nics/netvsc.rst
+++ b/doc/guides/nics/netvsc.rst
@@ -89,7 +89,7 @@ operations:
.. Note::
- The dpkd-devbind.py script can not be used since it only handles PCI devices.
+ The dpdk-devbind.py script can not be used since it only handles PCI devices.
Prerequisites
diff --git a/doc/guides/nics/nfb.rst b/doc/guides/nics/nfb.rst
index a7fb963..8df76c0 100644
--- a/doc/guides/nics/nfb.rst
+++ b/doc/guides/nics/nfb.rst
@@ -81,7 +81,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They are represented in DPDK as a single port.
-NFB-200G2QL card employs an addon cable which allows to connect it to two
+NFB-200G2QL card employs an add-on cable which allows to connect it to two
physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 09a8529..309fa5d 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -149,8 +149,8 @@ PF multiprocess support
-----------------------
Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary proceses with PF
-ports is limitted to only one.
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
This limitation will be solved in future versions but having basic multiprocess support
is important for allowing development and debugging through the PF using a secondary
diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index eb47f25..6d01d05 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -96,7 +96,7 @@ Non-supported Features
The features not yet supported include:
-- Receive queue interupts
+- Receive queue interrupts
- Priority-based flow control
@@ -209,12 +209,12 @@ Validating flow rules depends on the firmware variant.
The :ref:`flow_isolated_mode` is supported.
-Ethernet destinaton individual/group match
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ethernet destination individual/group match
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ethernet item supports I/G matching, if only the corresponding bit is set
-in the mask of destination address. If destinaton address in the spec is
-multicast, it matches all multicast (and broadcast) packets, oherwise it
+in the mask of destination address. If destination address in the spec is
+multicast, it matches all multicast (and broadcast) packets, otherwise it
matches unicast packets that are not filtered by other flow rules.
Exceptions to flow rules
@@ -348,10 +348,10 @@ boolean parameters value.
- ``perf_profile`` [auto|throughput|low-latency] (default **throughput**)
- Choose hardware tunning to be optimized for either throughput or
+ Choose hardware tuning to be optimized for either throughput or
low-latency.
**auto** allows NIC firmware to make a choice based on
- installed licences and firmware variant configured using **sfboot**.
+ installed licenses and firmware variant configured using **sfboot**.
- ``stats_update_period_ms`` [long] (default **1000**)
diff --git a/doc/guides/nics/szedata2.rst b/doc/guides/nics/szedata2.rst
index a2092f9..94dba82 100644
--- a/doc/guides/nics/szedata2.rst
+++ b/doc/guides/nics/szedata2.rst
@@ -89,7 +89,7 @@ The NFB cards are multi-port multi-queue cards, where (generally) data from any
Ethernet port may be sent to any queue.
They were historically represented in DPDK as a single port.
-However, the new NFB-200G2QL card employs an addon cable which allows to connect
+However, the new NFB-200G2QL card employs an add-on cable which allows to connect
it to two physical PCI-E slots at the same time (see the diagram below).
This is done to allow 200 Gbps of traffic to be transferred through the PCI-E
bus (note that a single PCI-E 3.0 x16 slot provides only 125 Gbps theoretical
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 063bd0b..4b6d77d 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -40,7 +40,7 @@ actual MAC address: ``00:64:74:61:70:[00-FF]``.
--vdev=net_tap0,mac="00:64:74:61:70:11"
The MAC address will have a user value passed as string. The MAC address is in
-format with delimeter ``:``. The string is byte converted to hex and you get
+format with delimiter ``:``. The string is byte converted to hex and you get
the actual MAC address: ``00:64:74:61:70:11``.
It is possible to specify a remote netdevice to capture packets from by adding
diff --git a/doc/guides/platform/dpaa.rst b/doc/guides/platform/dpaa.rst
index 3904871..6005f22 100644
--- a/doc/guides/platform/dpaa.rst
+++ b/doc/guides/platform/dpaa.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA Board Support Package
====================================
-This doc has information about steps to setup QorIq dpaa
+This doc has information about steps to setup QorIQ dpaa
based layerscape platform and information about common offload
hw block drivers of **NXP QorIQ DPAA** SoC family.
@@ -38,7 +38,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA PMD on a DPAA
+There are four main pre-requisites for executing DPAA PMD on a DPAA
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/platform/dpaa2.rst b/doc/guides/platform/dpaa2.rst
index 5a64406..2586af0 100644
--- a/doc/guides/platform/dpaa2.rst
+++ b/doc/guides/platform/dpaa2.rst
@@ -4,7 +4,7 @@
NXP QorIQ DPAA2 Board Support Package
=====================================
-This doc has information about steps to setup NXP QoriQ DPAA2 platform
+This doc has information about steps to setup NXP QorIQ DPAA2 platform
and information about common offload hw block drivers of
**NXP QorIQ DPAA2** SoC family.
@@ -48,7 +48,7 @@ Common Offload HW Block Drivers
Steps To Setup Platform
-----------------------
-There are four main pre-requisities for executing DPAA2 PMD on a DPAA2
+There are four main pre-requisites for executing DPAA2 PMD on a DPAA2
compatible board:
1. **ARM 64 Tool Chain**
diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index 9de1444..658ffd4 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -78,7 +78,7 @@ From the application point of view, each instance of a bbdev device consists of
one or more queues identified by queue IDs. While different devices may have
different capabilities (e.g. support different operation types), all queues on
a device support identical configuration possibilities. A queue is configured
-for only one type of operation and is configured at initializations time.
+for only one type of operation and is configured at initialization time.
When an operation is enqueued to a specific queue ID, the result is dequeued
from the same queue ID.
@@ -678,7 +678,7 @@ bbdev framework, by giving a sample code performing a loop-back operation with a
baseband processor capable of transceiving data packets.
The following sample C-like pseudo-code shows the basic steps to encode several
-buffers using (**sw_trubo**) bbdev PMD.
+buffers using (**sw_turbo**) bbdev PMD.
.. code-block:: c
diff --git a/doc/guides/prog_guide/compressdev.rst b/doc/guides/prog_guide/compressdev.rst
index ad97037..a06c835 100644
--- a/doc/guides/prog_guide/compressdev.rst
+++ b/doc/guides/prog_guide/compressdev.rst
@@ -17,7 +17,7 @@ Device Creation
Physical compression devices are discovered during the bus probe of the EAL function
which is executed at DPDK initialization, based on their unique device identifier.
-For eg. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
+For e.g. PCI devices can be identified using PCI BDF (bus/bridge, device, function).
Specific physical compression devices, like other physical devices in DPDK can be
white-listed or black-listed using the EAL command line options.
@@ -379,7 +379,7 @@ using priv_xform would look like:
setup op->m_src and op->m_dst;
}
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, comp_ops, NUM_OPS);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deque = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, NUM_OPS);
} while (num_dqud < num_enqd);
@@ -526,7 +526,7 @@ An example pseudocode to set up and process a stream having NUM_CHUNKS with each
op->src.length = CHUNK_LEN;
op->input_chksum = 0;
num_enqd = rte_compressdev_enqueue_burst(cdev_id, 0, &op[i], 1);
- /* wait for this to complete before enqueing next*/
+ /* wait for this to complete before enqueuing next*/
do {
num_deqd = rte_compressdev_dequeue_burst(cdev_id, 0 , &processed_ops, 1);
} while (num_deqd < num_enqd);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 74a930b..23fa5bc 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -14,7 +14,7 @@ and AEAD symmetric and asymmetric Crypto operations.
Design Principles
-----------------
-The cryptodev library follows the same basic principles as those used in DPDKs
+The cryptodev library follows the same basic principles as those used in DPDK's
Ethernet Device framework. The Crypto framework provides a generic Crypto device
framework which supports both physical (hardware) and virtual (software) Crypto
devices as well as a generic Crypto API which allows Crypto devices to be
@@ -48,7 +48,7 @@ From the command line using the --vdev EAL option
* If DPDK application requires multiple software crypto PMD devices then required
number of ``--vdev`` with appropriate libraries are to be added.
- * An Application with crypto PMD instaces sharing the same library requires unique ID.
+ * An Application with crypto PMD instances sharing the same library requires unique ID.
Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'``
@@ -396,7 +396,7 @@ Operation Management and Allocation
The cryptodev library provides an API set for managing Crypto operations which
utilize the Mempool Library to allocate operation buffers. Therefore, it ensures
-that the crytpo operation is interleaved optimally across the channels and
+that the crypto operation is interleaved optimally across the channels and
ranks for optimal processing.
A ``rte_crypto_op`` contains a field indicating the pool that it originated from.
When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool.
@@ -602,7 +602,7 @@ Sample code
There are various sample applications that show how to use the cryptodev library,
such as the L2fwd with Crypto sample application (L2fwd-crypto) and
-the IPSec Security Gateway application (ipsec-secgw).
+the IPsec Security Gateway application (ipsec-secgw).
While these applications demonstrate how an application can be created to perform
generic crypto operation, the required complexity hides the basic steps of
@@ -807,7 +807,7 @@ using one of the crypto PMDs available in DPDK.
/*
* Dequeue the crypto operations until all the operations
- * are proccessed in the crypto device.
+ * are processed in the crypto device.
*/
uint16_t num_dequeued_ops, total_num_dequeued_ops = 0;
do {
@@ -886,7 +886,7 @@ the order in which the transforms are passed indicates the order of the chaining
Not all asymmetric crypto xforms are supported for chaining. Currently supported
asymmetric crypto chaining is Diffie-Hellman private key generation followed by
public generation. Also, currently API does not support chaining of symmetric and
-asymmetric crypto xfroms.
+asymmetric crypto xforms.
Each xform defines specific asymmetric crypto algo. Currently supported are:
* RSA
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 96dbf30..74dba4d 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -204,7 +204,7 @@ Creates the following symbol:
Which ``dpdk-pmdinfogen`` scans for. Using this information other relevant
bits of data can be exported from the object file and used to produce a
hardware support description, that ``dpdk-pmdinfogen`` then encodes into a
-json formatted string in the following format:
+JSON formatted string in the following format:
.. code-block:: c
diff --git a/doc/guides/prog_guide/efd_lib.rst b/doc/guides/prog_guide/efd_lib.rst
index cb1a1df..2b355ff 100644
--- a/doc/guides/prog_guide/efd_lib.rst
+++ b/doc/guides/prog_guide/efd_lib.rst
@@ -423,6 +423,6 @@ References
1- EFD is based on collaborative research work between Intel and
Carnegie Mellon University (CMU), interested readers can refer to the paper
-“Scaling Up Clustered Network Appliances with ScaleBricks;” Dong Zhou et al.
+"Scaling Up Clustered Network Appliances with ScaleBricks" Dong Zhou et al.
at SIGCOMM 2015 (`http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p241.pdf`)
for more information.
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index fa8afdb..c27f730 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -733,7 +733,7 @@ The most important fields in the structure and how they are used are described b
Malloc heap is a doubly-linked list, where each element keeps track of its
previous and next elements. Due to the fact that hugepage memory can come and
-go, neighbouring malloc elements may not necessarily be adjacent in memory.
+go, neighboring malloc elements may not necessarily be adjacent in memory.
Also, since a malloc element may span multiple pages, its contents may not
necessarily be IOVA-contiguous either - each malloc element is only guaranteed
to be virtually contiguous.
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index e955299..c7dda92 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -162,7 +162,7 @@ The servicing_weight member of struct rte_event_eth_rx_adapter_queue_conf
is applicable when the adapter uses a service core function. The application
has to enable Rx queue interrupts when configuring the ethernet device
using the ``rte_eth_dev_configure()`` function and then use a servicing_weight
-of zero when addding the Rx queue to the adapter.
+of zero when adding the Rx queue to the adapter.
The adapter creates a thread blocked on the interrupt, on an interrupt this
thread enqueues the port id and the queue id to a ring buffer. The adapter
@@ -180,9 +180,9 @@ Rx Callback for SW Rx Adapter
For SW based packet transfers, i.e., when the
``RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT`` is not set in the adapter's
capabilities flags for a particular ethernet device, the service function
-temporarily enqueues mbufs to an event buffer before batch enqueueing these
+temporarily enqueues mbufs to an event buffer before batch enqueuing these
to the event device. If the buffer fills up, the service function stops
-dequeueing packets from the ethernet device. The application may want to
+dequeuing packets from the ethernet device. The application may want to
monitor the buffer fill level and instruct the service function to selectively
enqueue packets to the event device. The application may also use some other
criteria to decide which packets should enter the event device even when
diff --git a/doc/guides/prog_guide/eventdev.rst b/doc/guides/prog_guide/eventdev.rst
index dcdfeb7..7ea14ba 100644
--- a/doc/guides/prog_guide/eventdev.rst
+++ b/doc/guides/prog_guide/eventdev.rst
@@ -42,7 +42,7 @@ The rte_event structure contains the following metadata fields, which the
application fills in to have the event scheduled as required:
* ``flow_id`` - The targeted flow identifier for the enq/deq operation.
-* ``event_type`` - The source of this event, eg RTE_EVENT_TYPE_ETHDEV or CPU.
+* ``event_type`` - The source of this event, e.g. RTE_EVENT_TYPE_ETHDEV or CPU.
* ``sub_event_type`` - Distinguishes events inside the application, that have
the same event_type (see above)
* ``op`` - This field takes one of the RTE_EVENT_OP_* values, and tells the
@@ -265,7 +265,7 @@ Linking Queues and Ports
The final step is to "wire up" the ports to the queues. After this, the
eventdev is capable of scheduling events, and when cores request work to do,
the correct events are provided to that core. Note that the RX core takes input
-from eg: a NIC so it is not linked to any eventdev queues.
+from e.g.: a NIC so it is not linked to any eventdev queues.
Linking all workers to atomic queues, and the TX core to the single-link queue
can be achieved like this:
@@ -276,7 +276,7 @@ can be achieved like this:
uint8_t tx_port_id = 5;
uint8_t atomic_qs[] = {0, 1};
uint8_t single_link_q = 2;
- uin8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
+ uint8t_t priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
for(int worker_port_id = 1; worker_port_id <= 4; worker_port_id++) {
int links_made = rte_event_port_link(dev_id, worker_port_id, atomic_qs, NULL, 2);
diff --git a/doc/guides/prog_guide/ipsec_lib.rst b/doc/guides/prog_guide/ipsec_lib.rst
index 84696d4..6fc0888 100644
--- a/doc/guides/prog_guide/ipsec_lib.rst
+++ b/doc/guides/prog_guide/ipsec_lib.rst
@@ -65,7 +65,7 @@ In that mode the library functions perform
- check SQN
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
- check padding data
- remove outer IP header (tunnel mode) / update IP header (transport mode)
@@ -88,7 +88,7 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
- check SQN
- check padding data
@@ -101,10 +101,10 @@ In that mode the library functions perform
- generate SQN and IV
- add outer IP header (tunnel mode) / update IP header (transport mode)
- add ESP header and trailer, padding and IV data
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -113,15 +113,15 @@ In that mode the library functions perform
* for inbound packets:
- - verify that integity check and decryption performed by *rte_security*
+ - verify that integrity check and decryption performed by *rte_security*
device completed successfully
* for outbound packets:
- - update *ol_flags* inside *struct rte_mbuf* to inidicate that
+ - update *ol_flags* inside *struct rte_mbuf* to indicate that
inline-crypto processing has to be performed by HW on this packet
- invoke *rte_security* device specific *set_pkt_metadata()* to associate
- secuirty device specific data with the packet
+ security device specific data with the packet
RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -131,7 +131,7 @@ In that mode the library functions perform
* for inbound packets:
- prepare *rte_crypto_op* structure for each input packet
- - verify that integity check and decryption performed by crypto device
+ - verify that integrity check and decryption performed by crypto device
completed successfully
* for outbound packets:
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst
index 7fcbd93..daf87f4 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -227,7 +227,7 @@ application functions:
``config_promiscusity``:
- Called when the user changes the promiscusity state of the KNI
+ Called when the user changes the promiscuity state of the KNI
interface. For example, when the user runs ``ip link set promisc
[on|off] dev <ifaceX>``. If the user sets this callback function to
NULL, but sets the ``port_id`` field to a value other than -1, a default
diff --git a/doc/guides/prog_guide/metrics_lib.rst b/doc/guides/prog_guide/metrics_lib.rst
index e68e4e7..89bc7d6 100644
--- a/doc/guides/prog_guide/metrics_lib.rst
+++ b/doc/guides/prog_guide/metrics_lib.rst
@@ -25,7 +25,7 @@ individual device. Since the metrics library is self-contained, the only
restriction on port numbers is that they are less than ``RTE_MAX_ETHPORTS``
- there is no requirement for the ports to actually exist.
-Initialising the library
+Initializing the library
------------------------
Before the library can be used, it has to be initialized by calling
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 1384fe3..6196d3f 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -273,7 +273,7 @@ will be populated by IPC are as follows:
those peer processes that were active at the time of request, how many have
replied)
* ``msgs`` - pointer to where all of the responses are stored. The order in
- which responses appear is undefined. Whendoing sycnrhonous requests, this
+ which responses appear is undefined. When doing synchronous requests, this
memory must be freed by the requestor after request completes!
For asynchronous requests, a function pointer to the callback function must be
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 5af795c..a36ebef 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -64,7 +64,7 @@ The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
get a wall clock counter in user space. Typically it runs at <= 100MHz.
The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
-clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+clock counter is through the ARMv8 PMU subsystem. The PMU cycle counter runs
at CPU frequency. However, access to the PMU cycle counter from user space is
not enabled by default in the arm64 linux kernel. It is possible to enable
cycle counter for user space access by configuring the PMU from the privileged
@@ -75,7 +75,7 @@ scheme. Application can choose the PMU based implementation with
``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
The example below shows the steps to configure the PMU based cycle counter on
-an armv8 machine.
+an ARMv8 machine.
.. code-block:: console
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 0203f4f..937f52b 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2129,7 +2129,7 @@ as defined in the ``rte_flow_action_raw_decap``
This action modifies the payload of matched flows. The data supplied must
be a valid header, either holding layer 2 data in case of removing layer 2
-before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
+before encapsulation of layer 3 tunnel (for example MPLSoGRE) or complete
tunnel definition starting from layer 2 and moving to the tunnel item itself.
When applied to the original packet the resulting packet must be a
valid packet.
@@ -2279,7 +2279,7 @@ Action: ``DEC_TTL``
Decrease TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_dec_ttl:
@@ -2297,7 +2297,7 @@ Action: ``SET_TTL``
Assigns a new TTL value.
If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6
-in pattern, Some PMDs will reject rule because behaviour will be undefined.
+in pattern, Some PMDs will reject rule because behavior will be undefined.
.. _table_rte_flow_action_set_ttl:
@@ -2725,7 +2725,7 @@ Caveats
- API operations are synchronous and blocking (``EAGAIN`` cannot be
returned).
-- There is no provision for reentrancy/multi-thread safety, although nothing
+- There is no provision for re-entrancy/multi-thread safety, although nothing
should prevent different devices from being configured at the same
time. PMDs may protect their control path functions accordingly.
diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
index cb70caa..7d0734a 100644
--- a/doc/guides/prog_guide/rte_security.rst
+++ b/doc/guides/prog_guide/rte_security.rst
@@ -40,7 +40,7 @@ Inline Crypto
~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
-The crypto processing for security protocol (e.g. IPSec) is processed
+The crypto processing for security protocol (e.g. IPsec) is processed
inline during receive and transmission on NIC port. The flow based
security action should be configured on the port.
@@ -48,7 +48,7 @@ Ingress Data path - The packet is decrypted in RX path and relevant
crypto status is set in Rx descriptors. After the successful inline
crypto processing the packet is presented to host as a regular Rx packet
however all security protocol related headers are still attached to the
-packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will remain in the packet but the received packet
contains the decrypted data where the encrypted data was when the packet
arrived. The driver Rx path check the descriptors and and based on the
@@ -111,7 +111,7 @@ Inline protocol offload
~~~~~~~~~~~~~~~~~~~~~~~
RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
-The crypto and protocol processing for security protocol (e.g. IPSec)
+The crypto and protocol processing for security protocol (e.g. IPsec)
is processed inline during receive and transmission. The flow based
security action should be configured on the port.
@@ -119,7 +119,7 @@ Ingress Data path - The packet is decrypted in the RX path and relevant
crypto status is set in the Rx descriptors. After the successful inline
crypto processing the packet is presented to the host as a regular Rx packet
but all security protocol related headers are optionally removed from the
-packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
+packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
ESP/AH headers will be removed from the packet and the received packet
will contains the decrypted packet only. The driver Rx path checks the
descriptors and based on the crypto status sets additional flags in
@@ -132,7 +132,7 @@ to identify the security processing done on the packet.
The underlying device in this case is stateful. It is expected that
the device shall support crypto processing for all kind of packets matching
to a given flow, this includes fragmented packets (post reassembly).
- E.g. in case of IPSec the device may internally manage anti-replay etc.
+ E.g. in case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in the descriptor.
@@ -150,7 +150,7 @@ to cross the MTU size.
.. note::
The underlying device will manage state information required for egress
- processing. E.g. in case of IPSec, the seq number will be added to the
+ processing. E.g. in case of IPsec, the seq number will be added to the
packet, however the device shall provide indication when the sequence number
is about to overflow. The underlying device may support post encryption TSO.
@@ -199,13 +199,13 @@ crypto device.
Decryption: The packet is sent to the crypto device for security
protocol processing. The device will decrypt the packet and it will also
optionally remove additional security headers from the packet.
-E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
+E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
will be removed from the packet and the decrypted packet may contain
plain data only.
.. note::
- In case of IPSec the device may internally manage anti-replay etc.
+ In case of IPsec the device may internally manage anti-replay etc.
It will provide a configuration option for anti-replay behavior i.e. to drop
the packets or pass them to driver with error flags set in descriptor.
@@ -217,7 +217,7 @@ for any protocol header addition.
.. note::
- In the case of IPSec, the seq number will be added to the packet,
+ In the case of IPsec, the seq number will be added to the packet,
It shall provide an indication when the sequence number is about to
overflow.
@@ -549,7 +549,7 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform
struct rte_security_ipsec_sa_options options;
/**< various SA options */
enum rte_security_ipsec_sa_direction direction;
- /**< IPSec SA Direction - Egress/Ingress */
+ /**< IPsec SA Direction - Egress/Ingress */
enum rte_security_ipsec_sa_protocol proto;
/**< IPsec SA Protocol - AH/ESP */
enum rte_security_ipsec_sa_mode mode;
diff --git a/doc/guides/prog_guide/traffic_management.rst b/doc/guides/prog_guide/traffic_management.rst
index 98ac431..05b34d9 100644
--- a/doc/guides/prog_guide/traffic_management.rst
+++ b/doc/guides/prog_guide/traffic_management.rst
@@ -39,7 +39,7 @@ whether a specific implementation does meet the needs to the user application.
At the TM level, users can get high level idea with the help of various
parameters such as maximum number of nodes, maximum number of hierarchical
levels, maximum number of shapers, maximum number of private shapers, type of
-scheduling algorithm (Strict Priority, Weighted Fair Queueing , etc.), etc.,
+scheduling algorithm (Strict Priority, Weighted Fair Queuing , etc.), etc.,
supported by the implementation.
Likewise, users can query the capability of the TM at the hierarchical level to
diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst
index a86c07a..fc3ee43 100644
--- a/doc/guides/prog_guide/vhost_lib.rst
+++ b/doc/guides/prog_guide/vhost_lib.rst
@@ -63,7 +63,7 @@ The following is an overview of some key Vhost API functions:
512).
* zero copy is really good for VM2VM case. For iperf between two VMs, the
- boost could be above 70% (when TSO is enableld).
+ boost could be above 70% (when TSO is enabled).
* For zero copy in VM2NIC case, guest Tx used vring may be starved if the
PMD driver consume the mbuf but not release them timely.
diff --git a/doc/guides/rawdevs/ifpga_rawdev.rst b/doc/guides/rawdevs/ifpga_rawdev.rst
index d400db6..a3d92a6 100644
--- a/doc/guides/rawdevs/ifpga_rawdev.rst
+++ b/doc/guides/rawdevs/ifpga_rawdev.rst
@@ -91,7 +91,7 @@ Run-time parameters
-------------------
This driver is invoked automatically in systems added with Intel FPGA,
-but PR and IFPGA Bus scan is trigged by command line using
+but PR and IFPGA Bus scan is triggered by command line using
``--vdev 'ifpga_rawdev_cfg`` EAL option.
The following device parameters are supported:
diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst
index 358dfa3..276327c 100644
--- a/doc/guides/rel_notes/known_issues.rst
+++ b/doc/guides/rel_notes/known_issues.rst
@@ -676,7 +676,7 @@ igb uio legacy mode can not be used in X710/XL710/XXV710
**Description**:
X710/XL710/XXV710 NICs lack support for indicating INTx is asserted via the interrupt
- bit in the PCI status register. Linux delected them from INTx support table. The related
+ bit in the PCI status register. Linux deleted them from INTx support table. The related
`commit <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/pci/quirks.c?id=8bcf4525c5d43306c5fd07e132bc8650e3491aec>`_.
**Implication**:
@@ -722,9 +722,9 @@ Linux kernel 4.10.0 iommu attribute read error
**Description**:
When VT-d is enabled (``iommu=pt intel_iommu=on``), reading IOMMU attributes from
/sys/devices/virtual/iommu/dmarXXX/intel-iommu/cap on Linux kernel 4.10.0 error.
- This bug is fixed in `Linux commmit a7fdb6e648fb
+ This bug is fixed in `Linux commit a7fdb6e648fb
<https://patchwork.kernel.org/patch/9595727/>`_,
- This bug is introduced in `Linux commmit 39ab9555c241
+ This bug is introduced in `Linux commit 39ab9555c241
<https://patchwork.kernel.org/patch/9554403/>`_,
**Implication**:
@@ -842,7 +842,7 @@ AVX-512 support disabled
drop.
On DPDK v19.02 ``AVX-512`` disable scope is reduced to ``GCC`` and ``binutils version 2.30`` based
- on information accured from the GCC community defect.
+ on information accrued from the GCC community defect.
**Reason**:
Generated ``AVX-512`` code cause crash:
diff --git a/doc/guides/rel_notes/release_17_11.rst b/doc/guides/rel_notes/release_17_11.rst
index 2a93af3..6448b6c 100644
--- a/doc/guides/rel_notes/release_17_11.rst
+++ b/doc/guides/rel_notes/release_17_11.rst
@@ -168,7 +168,7 @@ New Features
* The DES CBC algorithm.
* The DES DOCSIS BPI algorithm.
- This change requires version 0.47 of the IPSec Multi-buffer library. For
+ This change requires version 0.47 of the IPsec Multi-buffer library. For
more details see the :doc:`../cryptodevs/aesni_mb` documentation.
* **Updated the OpenSSL PMD.**
@@ -198,7 +198,7 @@ New Features
* **Added the Security Offload Library.**
Added an experimental library - ``rte_security``. This provide security APIs
- for protocols like IPSec using inline ipsec offload to ethernet devices or
+ for protocols like IPsec using inline ipsec offload to ethernet devices or
full protocol offload with lookaside crypto devices.
See the :doc:`../prog_guide/rte_security` section of the DPDK Programmers
@@ -207,11 +207,11 @@ New Features
* **Updated the DPAA2_SEC crypto driver to support rte_security.**
Updated the ``dpaa2_sec`` crypto PMD to support ``rte_security`` lookaside
- protocol offload for IPSec.
+ protocol offload for IPsec.
* **Updated the IXGBE ethernet driver to support rte_security.**
- Updated ixgbe ethernet PMD to support ``rte_security`` inline IPSec offload.
+ Updated ixgbe ethernet PMD to support ``rte_security`` inline IPsec offload.
* **Updated i40e driver to support GTP-C/GTP-U.**
@@ -509,7 +509,7 @@ ABI Changes
* **New parameter added to rte_eth_dev.**
A new parameter ``security_ctx`` has been added to ``rte_eth_dev`` to
- support security operations like IPSec inline.
+ support security operations like IPsec inline.
* **New parameter added to rte_cryptodev.**
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 40a3264..405e706 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -68,7 +68,7 @@ The application accepts a number of command line options:
where:
-* ``e ENCODING_CORES``: hexmask for encoding lcored (default = 0x2)
+* ``e ENCODING_CORES``: hexmask for encoding lcores (default = 0x2)
* ``d DECODING_CORES``: hexmask for decoding lcores (default = 0x4)
* ``p ETH_PORT_ID``: ethernet port ID (default = 0)
* ``b BBDEV_ID``: BBDev ID (default = 0)
@@ -87,7 +87,7 @@ issue the command:
$ ./build/bbdev --vdev='baseband_turbo_sw' -w <NIC0PCIADDR> -c 0x38 --socket-mem=2,2 \
--file-prefix=bbdev -- -e 0x10 -d 0x20
-where, NIC0PCIADDR is the PCI addresse of the Rx port
+where, NIC0PCIADDR is the PCI address of the Rx port
This command creates one virtual bbdev devices ``baseband_turbo_sw`` where the
device gets linked to a corresponding ethernet port as whitelisted by
diff --git a/doc/guides/sample_app_ug/eventdev_pipeline.rst b/doc/guides/sample_app_ug/eventdev_pipeline.rst
index 0ec0290..dc7972a 100644
--- a/doc/guides/sample_app_ug/eventdev_pipeline.rst
+++ b/doc/guides/sample_app_ug/eventdev_pipeline.rst
@@ -49,7 +49,7 @@ these settings is shown below:
./build/eventdev_pipeline --vdev event_sw0 -- -r1 -t1 -e4 -w FF00 -s4 -n0 -c32 -W1000 -D
The application has some sanity checking built-in, so if there is a function
-(eg; the RX core) which doesn't have a cpu core mask assigned, the application
+(e.g.; the RX core) which doesn't have a cpu core mask assigned, the application
will print an error message:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst
index 159bcf7..9070419 100644
--- a/doc/guides/sample_app_ug/intro.rst
+++ b/doc/guides/sample_app_ug/intro.rst
@@ -106,7 +106,7 @@ examples are highlighted below.
(packet arrival) and TX (packet transmission) by adding callbacks to the RX
and TX packet processing functions.
-* :doc:`IPSec Security Gateway<ipsec_secgw>`: The IPSec Security
+* :doc:`IPsec Security Gateway<ipsec_secgw>`: The IPsec Security
Gateway application is minimal example of something closer to a real world
example. This is also a good example of an application using the DPDK
Cryptodev framework.
diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst
index 447a544..4da0fcf 100644
--- a/doc/guides/sample_app_ug/ip_pipeline.rst
+++ b/doc/guides/sample_app_ug/ip_pipeline.rst
@@ -113,7 +113,7 @@ Application stages
Initialization
~~~~~~~~~~~~~~
-During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data strcutures
+During this stage, EAL layer is initialised and application specific arguments are parsed. Furthermore, the data structures
(i.e. linked lists) for application objects are initialized. In case of any initialization error, an error message
is displayed and the application is terminated.
@@ -185,7 +185,7 @@ Examples
+-----------------------+----------------------+----------------+------------------------------------+
| IP routing | LPM (IPv4) | Forward | 1. Mempool Create |
| | | | 2. Link create |
- | | * Key = IP dest addr | | 3. Pipeline creat |
+ | | * Key = IP dest addr | | 3. Pipeline create |
| | * Offset = 286 | | 4. Pipeline port in/out |
| | * Table size = 4K | | 5. Pipeline table |
| | | | 6. Pipeline port in table |
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 3d784e7..ac118c1 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -25,8 +25,8 @@ The application classifies the ports as *Protected* and *Unprotected*.
Thus, traffic received on an Unprotected or Protected port is consider
Inbound or Outbound respectively.
-The application also supports complete IPSec protocol offload to hardware
-(Look aside crypto accelarator or using ethernet device). It also support
+The application also supports complete IPsec protocol offload to hardware
+(Look aside crypto accelerator or using ethernet device). It also support
inline ipsec processing by the supported ethernet device during transmission.
These modes can be selected during the SA creation configuration.
@@ -124,7 +124,7 @@ Where:
* ``-e``: enables Security Association extended sequence number processing
(available only with librte_ipsec code path).
-* ``-a``: enables Security Association sequence number atomic behaviour
+* ``-a``: enables Security Association sequence number atomic behavior
(available only with librte_ipsec code path).
* ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
@@ -752,7 +752,7 @@ DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
-It then tries to perform some data transfer using the scheme decribed above.
+It then tries to perform some data transfer using the scheme described above.
usage
~~~~~
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index e2c04ef..ac6ee8a 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -500,8 +500,8 @@ An application may save and retrieve a single pointer to application data in
the L-thread struct.
For legacy and backward compatibility reasons two alternative methods are also
-offered, the first is modelled directly on the pthread get/set specific APIs,
-the second approach is modelled on the ``RTE_PER_LCORE`` macros, whereby
+offered, the first is modeled directly on the pthread get/set specific APIs,
+the second approach is modeled on the ``RTE_PER_LCORE`` macros, whereby
``PER_LTHREAD`` macros are introduced, in both cases the storage is local to
the L-thread.
diff --git a/doc/guides/sample_app_ug/qos_metering.rst b/doc/guides/sample_app_ug/qos_metering.rst
index 2e8e017..d75f7da 100644
--- a/doc/guides/sample_app_ug/qos_metering.rst
+++ b/doc/guides/sample_app_ug/qos_metering.rst
@@ -151,5 +151,5 @@ In this particular case:
* For the rest of the cases, the color is changed to red.
.. note::
- * In color blind mode, first row GREEN colour is only valid.
+ * In color blind mode, first row GREEN color is only valid.
* To drop the packet, policer_table action has to be set to DROP.
diff --git a/doc/guides/sample_app_ug/test_pipeline.rst b/doc/guides/sample_app_ug/test_pipeline.rst
index 5f313c5..5aefd8d 100644
--- a/doc/guides/sample_app_ug/test_pipeline.rst
+++ b/doc/guides/sample_app_ug/test_pipeline.rst
@@ -32,7 +32,7 @@ Compiling the Application
-------------------------
To compile the sample application see :doc:`compiling`
-The application is located in the ``$RTE_SDK/app/test-pipline`` directory.
+The application is located in the ``$RTE_SDK/app/test-pipeline`` directory.
Running the Application
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index df4d6f9..a71ada6 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -116,7 +116,7 @@ will create it. Put simply, it's the server to create the socket file.
The vm2vm parameter sets the mode of packet switching between guests in
the host.
-- 0 disables vm2vm, impling that VM's packets will always go to the NIC port.
+- 0 disables vm2vm, implying that VM's packets will always go to the NIC port.
- 1 means a normal mac lookup packet routing.
- 2 means hardware mode packet forwarding between guests, it allows packets
go to the NIC port, hardware L2 switch will determine which guest the
@@ -148,7 +148,7 @@ default value is 15.
**--dequeue-zero-copy**
Dequeue zero copy will be enabled when this option is given. it is worth to
-note that if NIC is binded to driver with iommu enabled, dequeue zero copy
+note that if NIC is bound to driver with iommu enabled, dequeue zero copy
cannot work at VM2NIC mode (vm2vm=0) due to currently we don't setup iommu
dma mapping for guest memory.
diff --git a/doc/guides/sample_app_ug/vhost_scsi.rst b/doc/guides/sample_app_ug/vhost_scsi.rst
index 7ab7d0d..6b9bf62 100644
--- a/doc/guides/sample_app_ug/vhost_scsi.rst
+++ b/doc/guides/sample_app_ug/vhost_scsi.rst
@@ -63,7 +63,7 @@ Vhost_scsi Common Issues
* vhost_scsi can not start with block size 512 Bytes:
- Currently DPDK vhost library was designed for NET device(althrough the APIs
+ Currently DPDK vhost library was designed for NET device(although the APIs
are generic now), for 512 Bytes block device, Qemu BIOS(x86 BIOS Enhanced
Disk Device) will enumerate all block device and do some IOs to those block
devices with 512 Bytes sector size. DPDK vhost library can not process such
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e..109d109 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -344,7 +344,7 @@ monitoring of branch ratio on cores doing busy polling via PMDs.
When this parameter is used, the list of cores specified will monitor the ratio
between branch hits and branch misses. A tightly polling PMD thread will have a
- very low branch ratio, so the core frequency will be scaled down to the minimim
+ very low branch ratio, so the core frequency will be scaled down to the minimum
allowed value. When packets are received, the code path will alter, causing the
branch ratio to increase. When the ratio goes above the ratio threshold, the
core frequency will be scaled up to the maximum allowed value.
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The JSON string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -734,7 +734,7 @@ policy down to the host application. These parameters are as follows:
A comma-separated list of cores in the VM that the user wants the host application to
monitor. The list of cores in any vm starts at zero, and these are mapped to the
physical cores by the host application once the policy is passed down.
- Valid syntax includes individial cores '2,3,4', or a range of cores '2-4', or a
+ Valid syntax includes individual cores '2,3,4', or a range of cores '2-4', or a
combination of both '1,3,5-7'
.. code-block:: console
@@ -742,7 +742,7 @@ policy down to the host application. These parameters are as follows:
--busy-hours {list of busy hours}
A comma-separated list of hours within which to set the core frequency to maximum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
@@ -750,7 +750,7 @@ policy down to the host application. These parameters are as follows:
--quiet-hours {list of quiet hours}
A comma-separated list of hours within which to set the core frequency to minimum.
- Valid syntax includes individial hours '2,3,4', or a range of hours '2-4', or a
+ Valid syntax includes individual hours '2,3,4', or a range of hours '2-4', or a
combination of both '1,3,5-7'. Valid hours are 0 to 23.
.. code-block:: console
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst
index fdf6ec7..e7db520 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -381,7 +381,7 @@ The command line options are:
* ``--hot-plug``
- Enable device event monitor mechanism for hot plug.
+ Enable device event monitor mechanism for hotplug.
* ``--vxlan-gpe-port=N``
@@ -421,23 +421,23 @@ The command line options are:
* ``--noisy-lkup-memory=N``
- Set the size of the noisy neighbour simulation memory buffer in MB to N.
+ Set the size of the noisy neighbor simulation memory buffer in MB to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads=N``
- Set the number of reads to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of reads to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-writes=N``
- Set the number of writes to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of writes to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--noisy-lkup-num-reads-writes=N``
- Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N.
+ Set the number of r/w accesses to be done in noisy neighbor simulation memory buffer to N.
Only available with the noisy forwarding mode. The default value is 0.
* ``--no-iova-contig``
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 5d4dc6f..e602df5 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -303,7 +303,7 @@ The available information categories are:
This is the default mode.
* ``mac``: Changes the source and the destination Ethernet addresses of packets before forwarding them.
- Default application behaviour is to set source Ethernet address to that of the transmitting interface, and destination
+ Default application behavior is to set source Ethernet address to that of the transmitting interface, and destination
address to a dummy value (set during init). The user may specify a target destination Ethernet address via the 'eth-peer' or
'eth-peers-configfile' command-line options. It is not currently possible to specify a specific source Ethernet address.
@@ -326,7 +326,7 @@ The available information categories are:
* ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is
similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``.
-* ``noisy``: Noisy neighbour simulation.
+* ``noisy``: Noisy neighbor simulation.
Simulate more realistic behavior of a guest machine engaged in receiving
and sending packets performing Virtual Network Function (VNF).
@@ -2289,7 +2289,7 @@ set bonding lacp dedicated_queue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enable dedicated tx/rx queues on bonding devices slaves to handle LACP control plane traffic
-when in mode 4 (link-aggregration-802.3ad)::
+when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding lacp dedicated_queues (port_id) (enable|disable)
@@ -2297,7 +2297,7 @@ when in mode 4 (link-aggregration-802.3ad)::
set bonding agg_mode
~~~~~~~~~~~~~~~~~~~~
-Enable one of the specific aggregators mode when in mode 4 (link-aggregration-802.3ad)::
+Enable one of the specific aggregators mode when in mode 4 (link-aggregation-802.3ad)::
testpmd> set bonding agg_mode (port_id) (bandwidth|count|stable)
@@ -2691,8 +2691,8 @@ where:
* ``shared_shaper_id``: Shared shaper ID to be deleted.
-Set port traffic management hiearchy node private shaper
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Set port traffic management hierarchy node private shaper
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
set the port traffic management hierarchy node private shaper::
@@ -2743,7 +2743,7 @@ Delete the WRED profile::
Add port traffic management hierarchy nonleaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add nonleaf node to port traffic management hiearchy::
+Add nonleaf node to port traffic management hierarchy::
testpmd> add port tm nonleaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2758,7 +2758,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``n_sp_priorities``: Number of strict priorities.
@@ -2769,7 +2769,7 @@ where:
Add port traffic management hierarchy leaf node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Add leaf node to port traffic management hiearchy::
+Add leaf node to port traffic management hierarchy::
testpmd> add port tm leaf node (port_id) (node_id) (parent_node_id) \
(priority) (weight) (level_id) (shaper_profile_id) \
@@ -2784,7 +2784,7 @@ where:
* ``weight``: Node weight (lowest weight is one). The node weight is relative
to the weight sum of all siblings that have the same priority. It is used by
the WFQ algorithm running on the parent node for scheduling this node.
-* ``level_id``: Hiearchy level of the node.
+* ``level_id``: Hierarchy level of the node.
* ``shaper_profile_id``: Shaper profile ID of the private shaper to be used by
the node.
* ``cman_mode``: Congestion management mode to be enabled for this node.
@@ -2796,7 +2796,7 @@ where:
Delete port traffic management hierarchy node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Delete node from port traffic management hiearchy::
+Delete node from port traffic management hierarchy::
testpmd> del port tm node (port_id) (node_id)
@@ -3989,7 +3989,7 @@ This section lists supported actions and their attributes, if any.
- ``dec_ttl``: Performs a decrease TTL value action
-- ``set_ttl``: Set TTL value with specificed value
+- ``set_ttl``: Set TTL value with specified value
- ``ttl_value {unsigned}``: The new TTL value to be set
- ``set_mac_src``: set source MAC address
@@ -4522,7 +4522,7 @@ The following sections show functions to load/unload eBPF based filters.
bpf-load
~~~~~~~~
-Load an eBPF program as a callback for partciular RX/TX queue::
+Load an eBPF program as a callback for particular RX/TX queue::
testpmd> bpf-load rx|tx (portid) (queueid) (load-flags) (bpf-prog-filename)
@@ -4560,7 +4560,7 @@ To load (not JITed) t1.o at TX queue 0, port 0::
bpf-unload
~~~~~~~~~~
-Unload previously loaded eBPF program for partciular RX/TX queue::
+Unload previously loaded eBPF program for particular RX/TX queue::
testpmd> bpf-unload rx|tx (portid) (queueid)
diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst
index c366af4..2fc6544 100644
--- a/doc/guides/tools/cryptoperf.rst
+++ b/doc/guides/tools/cryptoperf.rst
@@ -59,7 +59,7 @@ To set on the linearization options add below definition to the
**Step 3: Build the application**
Execute the ``dpdk-setup.sh`` script to build the DPDK library together with the
-``dpdk-test-crypto-perf`` applcation.
+``dpdk-test-crypto-perf`` application.
Initially, the user must select a DPDK target to choose the correct target type
and compiler options to use when building the libraries.
@@ -80,7 +80,7 @@ EAL Options
~~~~~~~~~~~
The following are the EAL command-line options that can be used in conjunction
-with the ``dpdk-test-crypto-perf`` applcation.
+with the ``dpdk-test-crypto-perf`` application.
See the DPDK Getting Started Guides for more information on these options.
* ``-c <COREMASK>`` or ``-l <CORELIST>``
@@ -96,10 +96,10 @@ See the DPDK Getting Started Guides for more information on these options.
Add a virtual device.
-Appication Options
-~~~~~~~~~~~~~~~~~~
+Application Options
+~~~~~~~~~~~~~~~~~~~
-The following are the appication command-line options:
+The following are the application command-line options:
* ``--ptest type``
@@ -338,13 +338,13 @@ Test Vector File
The test vector file is a text file contain information about test vectors.
The file is made of the sections. The first section doesn't have header.
It contain global information used in each test variant vectors -
-typically information about plaintext, ciphertext, cipher key, aut key,
+typically information about plaintext, ciphertext, cipher key, auth key,
initial vector. All other sections begin header.
The sections contain particular information typically digest.
**Format of the file:**
-Each line beginig with sign '#' contain comment and it is ignored by parser::
+Each line beginning with sign '#' contain comment and it is ignored by parser::
# <comment>
@@ -352,16 +352,16 @@ Header line is just name in square bracket::
[<section name>]
-Data line contain information tocken then sign '=' and
+Data line contain information token then sign '=' and
a string of bytes in C byte array format::
- <tocken> = <C byte array>
+ <token> = <C byte array>
-**Tockens list:**
+**Tokens list:**
* ``plaintext``
- Original plaintext to be crypted.
+ Original plaintext to be encrypted.
* ``ciphertext``
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst
index 6bdf5a8..2ea1b59 100644
--- a/doc/guides/tools/proc_info.rst
+++ b/doc/guides/tools/proc_info.rst
@@ -44,7 +44,7 @@ If no port mask is specified xstats are reset for all DPDK ports.
**-m**: Print DPDK memory information.
**--show-port**
-The show-port parameter displays port level various configuration informationi
+The show-port parameter displays port level various configuration information
associated to RX port queue pair.
**--show-tm**
@@ -56,7 +56,7 @@ The show-crypto parameter displays available cryptodev configurations,
settings and stats per node.
**--show-ring[=name]**
-The show-ring pararmeter display current allocation of all ring with
+The show-ring parameter display current allocation of all ring with
debug information. Specifying the name allows to display details for specific
ring. For invalid or no ring name, whole list is dump.
@@ -76,7 +76,7 @@ Limitations
* When running ``dpdk-procinfo`` with shared library mode, it is required to
pass the same NIC PMD libraries as used for the primary application. Any
- mismatch in PMD library arguments can lead to undefined behaviour and results
+ mismatch in PMD library arguments can lead to undefined behavior and results
affecting primary application too.
* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP.
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 07da35e..7e6a4db 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -139,7 +139,7 @@ There are 6 main test cases that can be executed using testbbdev tool:
* Latency measurement [-c latency]
- Measures the time consumed from the first enqueue until the first
appearance of a dequeued result
- - This measurment represents the full latency of a bbdev operation
+ - This measurement represents the full latency of a bbdev operation
(encode or decode) to execute
* Poll-mode Throughput measurement [-c throughput]
--
2.7.5
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
@ 2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
0 siblings, 2 replies; 200+ results
From: Tiwei Bie @ 2019-04-28 11:17 UTC (permalink / raw)
To: Li Lin
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> From: lilin24 <lilin24@baidu.com>
>
> This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> buffer between qemu and backend.
>
> Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> shared buffer from backend. Then qemu should send it back
> through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
>
> This shared buffer is used to process inflight I/O when backend
> reconnect.
>
> Signed-off-by: lilin24 <lilin24@baidu.com>
You need to use your real name here.
> Signed-off-by: Ni Xun <nixun@baidu.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>
> v2:
> - add set&clr inflight entry function
> v3:
> - simplified some function implementations
>
> ---
You can put change logs here (i.e. after ---).
> lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> lib/librte_vhost/vhost.c | 42 ++++++++
> lib/librte_vhost/vhost.h | 11 ++
> lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 16 ++-
> 5 files changed, 351 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index d2c0c93f4..bc25591a8 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -71,6 +71,10 @@ extern "C" {
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> +#endif
> +
> /** Indicate whether protocol features negotiation is supported. */
> #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> #define VHOST_USER_F_PROTOCOL_FEATURES 30
> @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> struct rte_vhost_mem_region regions[];
> };
>
> +typedef struct VhostUserInflightEntry {
> + uint8_t inflight;
> +} VhostUserInflightEntry;
> +
> +typedef struct VhostInflightInfo {
> + uint16_t version;
> + uint16_t last_inflight_io;
> + uint16_t used_idx;
> + VhostUserInflightEntry desc[0];
> +} VhostInflightInfo;
Is there any details on above structure? Why does it not match
QueueRegionSplit or QueueRegionPacked structures described in
qemu/docs/interop/vhost-user.txt?
> +
> struct rte_vhost_vring {
> struct vring_desc *desc;
> struct vring_avail *avail;
> struct vring_used *used;
> uint64_t log_guest_addr;
>
> + VhostInflightInfo *inflight;
> + int inflight_flag;
> +
> /** Deprecated, use rte_vhost_vring_call() instead. */
> int callfd;
>
> @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> int rte_vhost_vring_call(int vid, uint16_t vring_idx);
>
> /**
> + * set inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> + uint16_t idx);
> +
> +/**
> + * clear inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param last_used_idx
> + * next free used_idx
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx);
> +
> +/**
> + * set last inflight io index.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> + uint16_t idx);
New APIs should be experimental and also need to be
added in rte_vhost_version.map file.
> +
> +/**
> * Get vhost RX queue avail count.
> *
> * @param vid
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index 163f4595e..9ba692935 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> close(vq->callfd);
> if (vq->kickfd >= 0)
> close(vq->kickfd);
> + if (vq->inflight)
> + vq->inflight = NULL;
> }
>
> /*
> @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> vring->kickfd = vq->kickfd;
> vring->size = vq->size;
>
> + vring->inflight = vq->inflight;
> +
> + vring->inflight_flag = vq->inflight_flag;
> + vq->inflight_flag = 0;
This will break the ABI. Better to introduce a new API to do this.
> +
> return 0;
> }
>
> @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> return 0;
> }
>
> +void
> +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> + if (unlikely(!inflight))
> + return;
> + inflight->desc[idx].inflight = 1;
> +}
> +
> +void
> +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + rte_compiler_barrier();
> + inflight->desc[idx].inflight = 0;
> + rte_compiler_barrier();
> + inflight->used_idx = last_used_idx;
> +}
> +
> +void
> +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + inflight->last_inflight_io = idx;
> +}
The rte_vhost_vring is used to return information to apps.
IIUC, you want to update vq->inflight. So the rte_vhost_vring
param should be replaced by vid + vring_idx.
> +
> uint16_t
> rte_vhost_avail_entries(int vid, uint16_t queue_id)
> {
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index e9138dfab..537d74c71 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> /* Physical address of used ring, for logging */
> uint64_t log_guest_addr;
>
> + /* Inflight share memory info */
> + VhostInflightInfo *inflight;
> + bool inflight_flag;
> +
> uint16_t nr_zmbuf;
> uint16_t zmbuf_size;
> uint16_t last_zmbuf_idx;
> @@ -286,6 +290,12 @@ struct guest_page {
> uint64_t size;
> };
>
> +typedef struct VuDevInflightInfo {
> + int fd;
> + void *addr;
> + uint64_t size;
> +} VuDevInflightInfo;
Please follow DPDK's coding style when defining internal structure.
> +
> /**
> * Device structure contains all configuration information relating
> * to the device.
> @@ -303,6 +313,7 @@ struct virtio_net {
> uint32_t nr_vring;
> int dequeue_zero_copy;
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> + VuDevInflightInfo inflight_info;
> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> char ifname[IF_NAME_SZ];
> uint64_t log_size;
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
[...]
> +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> +{
> + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> +}
> +
> +static int
> +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd;
> + uint64_t mmap_size;
> + void *addr;
> + uint16_t num_queues, queue_size;
> + struct virtio_net *dev = *pdev;
> +
> + if (msg->size != sizeof(msg->payload.inflight)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Invalid get_inflight_fd message size is %d",
> + msg->size);
> + msg->payload.inflight.mmap_size = 0;
In this case, you can't touch the payload.
> + return 0;
And an error should be returned.
> + }
> +
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> +
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> + msg->payload.inflight.num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> + msg->payload.inflight.queue_size);
> + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> +
> + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> + if (!addr) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> + msg->payload.inflight.mmap_size = 0;
> + return 0;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> + memset(addr, 0, mmap_size);
> +
> + dev->inflight_info.addr = addr;
> + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> + dev->inflight_info.fd = msg->fds[0] = fd;
> + msg->payload.inflight.mmap_offset = 0;
> + msg->fd_num = 1;
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_size: %lu\n",
> + msg->payload.inflight.mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_offset: %lu\n",
> + msg->payload.inflight.mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight fd: %d\n", msg->fds[0]);
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd, i;
> + uint64_t mmap_size, mmap_offset;
> + uint16_t num_queues, queue_size;
> + uint32_t pervq_inflight_size;
> + void *rc;
> + struct vhost_virtqueue *vq;
> + struct virtio_net *dev = *pdev;
> +
> + fd = msg->fds[0];
> + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> + msg->size, fd);
> + return -1;
Ditto.
> + }
> +
> + mmap_size = msg->payload.inflight.mmap_size;
> + mmap_offset = msg->payload.inflight.mmap_offset;
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> + pervq_inflight_size = get_pervq_shm_size(queue_size);
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd num_queues: %u\n", num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd queue_size: %u\n", queue_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd fd: %d\n", fd);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd pervq_inflight_size: %d\n",
> + pervq_inflight_size);
> +
> + if (dev->inflight_info.addr)
> + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> +
> + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> + fd, mmap_offset);
Why call it rc? Maybe addr is a better name?
> + if (rc == MAP_FAILED) {
> + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> + return -1;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> +
> + if (dev->inflight_info.fd)
> + close(dev->inflight_info.fd);
> +
> + dev->inflight_info.fd = fd;
> + dev->inflight_info.addr = rc;
> + dev->inflight_info.size = mmap_size;
> +
> + for (i = 0; i < num_queues; i++) {
> + vq = dev->virtqueue[i];
> + vq->inflight = (VhostInflightInfo *)rc;
> + rc = (void *)((char *)rc + pervq_inflight_size);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> static int
> vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> }
>
> static int
> +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> +{
> + uint16_t i = 0;
> +
> + if ((!vq->inflight))
> + return RTE_VHOST_MSG_RESULT_ERR;
Should check whether the feature is negotiated first.
> +
> + if (!vq->inflight->version) {
> + vq->inflight->version = INFLIGHT_VERSION;
> + return RTE_VHOST_MSG_RESULT_OK;
> + }
> +
> + for (i = 0; i < vq->size; i++) {
> + if (vq->inflight->desc[i].inflight == 1) {
> + vq->inflight_flag = 1;
> + break;
> + }
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> +static int
> vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> {
> @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> close(vq->kickfd);
> vq->kickfd = file.fd;
>
> + if (vhost_check_queue_inflights(vq)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Failed to inflights for vq: %d\n", file.index);
> + return RTE_VHOST_MSG_RESULT_ERR;
> + }
> +
> return RTE_VHOST_MSG_RESULT_OK;
> }
>
> @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> };
>
>
> diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> index 2a650fe4b..35f969b1b 100644
> --- a/lib/librte_vhost/vhost_user.h
> +++ b/lib/librte_vhost/vhost_user.h
> @@ -23,7 +23,8 @@
> (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
It will advertise this feature for builtin net and crypto
backends. It's probably not what you intended.
>
> typedef enum VhostUserRequest {
> VHOST_USER_NONE = 0,
> @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> - VHOST_USER_MAX = 31
> + VHOST_USER_GET_INFLIGHT_FD = 31,
> + VHOST_USER_SET_INFLIGHT_FD = 32,
> + VHOST_USER_MAX = 33
> } VhostUserRequest;
>
> typedef enum VhostUserSlaveRequest {
> @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> uint64_t offset;
> } VhostUserVringArea;
>
> +typedef struct VhostUserInflight {
> + uint64_t mmap_size;
> + uint64_t mmap_offset;
> + uint16_t num_queues;
> + uint16_t queue_size;
> +} VhostUserInflight;
> +
> typedef struct VhostUserMsg {
> union {
> uint32_t master; /* a VhostUserRequest value */
> @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> struct vhost_vring_addr addr;
> VhostUserMemory memory;
> VhostUserLog log;
> + VhostUserInflight inflight;
> struct vhost_iotlb_msg iotlb;
> VhostUserCryptoSessionParam crypto_session;
> VhostUserVringArea area;
> @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> /* vhost_user.c */
> int vhost_user_msg_handler(int vid, int fd);
> int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
>
> /* socket.c */
> int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> --
> 2.11.0
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-28 11:17 3% ` Tiwei Bie
@ 2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
1 sibling, 0 replies; 200+ results
From: Tiwei Bie @ 2019-04-28 11:17 UTC (permalink / raw)
To: Li Lin
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> From: lilin24 <lilin24@baidu.com>
>
> This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> buffer between qemu and backend.
>
> Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> shared buffer from backend. Then qemu should send it back
> through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
>
> This shared buffer is used to process inflight I/O when backend
> reconnect.
>
> Signed-off-by: lilin24 <lilin24@baidu.com>
You need to use your real name here.
> Signed-off-by: Ni Xun <nixun@baidu.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
>
> v2:
> - add set&clr inflight entry function
> v3:
> - simplified some function implementations
>
> ---
You can put change logs here (i.e. after ---).
> lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> lib/librte_vhost/vhost.c | 42 ++++++++
> lib/librte_vhost/vhost.h | 11 ++
> lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 16 ++-
> 5 files changed, 351 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index d2c0c93f4..bc25591a8 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -71,6 +71,10 @@ extern "C" {
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> +#endif
> +
> /** Indicate whether protocol features negotiation is supported. */
> #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> #define VHOST_USER_F_PROTOCOL_FEATURES 30
> @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> struct rte_vhost_mem_region regions[];
> };
>
> +typedef struct VhostUserInflightEntry {
> + uint8_t inflight;
> +} VhostUserInflightEntry;
> +
> +typedef struct VhostInflightInfo {
> + uint16_t version;
> + uint16_t last_inflight_io;
> + uint16_t used_idx;
> + VhostUserInflightEntry desc[0];
> +} VhostInflightInfo;
Is there any details on above structure? Why does it not match
QueueRegionSplit or QueueRegionPacked structures described in
qemu/docs/interop/vhost-user.txt?
> +
> struct rte_vhost_vring {
> struct vring_desc *desc;
> struct vring_avail *avail;
> struct vring_used *used;
> uint64_t log_guest_addr;
>
> + VhostInflightInfo *inflight;
> + int inflight_flag;
> +
> /** Deprecated, use rte_vhost_vring_call() instead. */
> int callfd;
>
> @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> int rte_vhost_vring_call(int vid, uint16_t vring_idx);
>
> /**
> + * set inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> + uint16_t idx);
> +
> +/**
> + * clear inflight flag for a entry.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param last_used_idx
> + * next free used_idx
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx);
> +
> +/**
> + * set last inflight io index.
> + *
> + * @param vring
> + * the structure to hold the requested vring info
> + * @param idx
> + * inflight entry index
> + */
> +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> + uint16_t idx);
New APIs should be experimental and also need to be
added in rte_vhost_version.map file.
> +
> +/**
> * Get vhost RX queue avail count.
> *
> * @param vid
> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> index 163f4595e..9ba692935 100644
> --- a/lib/librte_vhost/vhost.c
> +++ b/lib/librte_vhost/vhost.c
> @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> close(vq->callfd);
> if (vq->kickfd >= 0)
> close(vq->kickfd);
> + if (vq->inflight)
> + vq->inflight = NULL;
> }
>
> /*
> @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> vring->kickfd = vq->kickfd;
> vring->size = vq->size;
>
> + vring->inflight = vq->inflight;
> +
> + vring->inflight_flag = vq->inflight_flag;
> + vq->inflight_flag = 0;
This will break the ABI. Better to introduce a new API to do this.
> +
> return 0;
> }
>
> @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> return 0;
> }
>
> +void
> +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> + if (unlikely(!inflight))
> + return;
> + inflight->desc[idx].inflight = 1;
> +}
> +
> +void
> +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> + uint16_t last_used_idx, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + rte_compiler_barrier();
> + inflight->desc[idx].inflight = 0;
> + rte_compiler_barrier();
> + inflight->used_idx = last_used_idx;
> +}
> +
> +void
> +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> +{
> + VhostInflightInfo *inflight = vring->inflight;
> +
> + if (unlikely(!inflight))
> + return;
> +
> + inflight->last_inflight_io = idx;
> +}
The rte_vhost_vring is used to return information to apps.
IIUC, you want to update vq->inflight. So the rte_vhost_vring
param should be replaced by vid + vring_idx.
> +
> uint16_t
> rte_vhost_avail_entries(int vid, uint16_t queue_id)
> {
> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> index e9138dfab..537d74c71 100644
> --- a/lib/librte_vhost/vhost.h
> +++ b/lib/librte_vhost/vhost.h
> @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> /* Physical address of used ring, for logging */
> uint64_t log_guest_addr;
>
> + /* Inflight share memory info */
> + VhostInflightInfo *inflight;
> + bool inflight_flag;
> +
> uint16_t nr_zmbuf;
> uint16_t zmbuf_size;
> uint16_t last_zmbuf_idx;
> @@ -286,6 +290,12 @@ struct guest_page {
> uint64_t size;
> };
>
> +typedef struct VuDevInflightInfo {
> + int fd;
> + void *addr;
> + uint64_t size;
> +} VuDevInflightInfo;
Please follow DPDK's coding style when defining internal structure.
> +
> /**
> * Device structure contains all configuration information relating
> * to the device.
> @@ -303,6 +313,7 @@ struct virtio_net {
> uint32_t nr_vring;
> int dequeue_zero_copy;
> struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> + VuDevInflightInfo inflight_info;
> #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> char ifname[IF_NAME_SZ];
> uint64_t log_size;
> diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
[...]
> +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> +{
> + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> +}
> +
> +static int
> +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd;
> + uint64_t mmap_size;
> + void *addr;
> + uint16_t num_queues, queue_size;
> + struct virtio_net *dev = *pdev;
> +
> + if (msg->size != sizeof(msg->payload.inflight)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Invalid get_inflight_fd message size is %d",
> + msg->size);
> + msg->payload.inflight.mmap_size = 0;
In this case, you can't touch the payload.
> + return 0;
And an error should be returned.
> + }
> +
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> +
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> + msg->payload.inflight.num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> + msg->payload.inflight.queue_size);
> + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> +
> + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> + if (!addr) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> + msg->payload.inflight.mmap_size = 0;
> + return 0;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> + memset(addr, 0, mmap_size);
> +
> + dev->inflight_info.addr = addr;
> + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> + dev->inflight_info.fd = msg->fds[0] = fd;
> + msg->payload.inflight.mmap_offset = 0;
> + msg->fd_num = 1;
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_size: %lu\n",
> + msg->payload.inflight.mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight mmap_offset: %lu\n",
> + msg->payload.inflight.mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "send inflight fd: %d\n", msg->fds[0]);
> +
> + return RTE_VHOST_MSG_RESULT_REPLY;
> +}
> +
> +static int
> +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> + int main_fd __rte_unused)
> +{
> + int fd, i;
> + uint64_t mmap_size, mmap_offset;
> + uint16_t num_queues, queue_size;
> + uint32_t pervq_inflight_size;
> + void *rc;
> + struct vhost_virtqueue *vq;
> + struct virtio_net *dev = *pdev;
> +
> + fd = msg->fds[0];
> + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> + msg->size, fd);
> + return -1;
Ditto.
> + }
> +
> + mmap_size = msg->payload.inflight.mmap_size;
> + mmap_offset = msg->payload.inflight.mmap_offset;
> + num_queues = msg->payload.inflight.num_queues;
> + queue_size = msg->payload.inflight.queue_size;
> + pervq_inflight_size = get_pervq_shm_size(queue_size);
> +
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd num_queues: %u\n", num_queues);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd queue_size: %u\n", queue_size);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd fd: %d\n", fd);
> + RTE_LOG(INFO, VHOST_CONFIG,
> + "set_inflight_fd pervq_inflight_size: %d\n",
> + pervq_inflight_size);
> +
> + if (dev->inflight_info.addr)
> + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> +
> + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> + fd, mmap_offset);
Why call it rc? Maybe addr is a better name?
> + if (rc == MAP_FAILED) {
> + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> + return -1;
Should always return RTE_VHOST_MSG_RESULT_* in
message handler.
> + }
> +
> + if (dev->inflight_info.fd)
> + close(dev->inflight_info.fd);
> +
> + dev->inflight_info.fd = fd;
> + dev->inflight_info.addr = rc;
> + dev->inflight_info.size = mmap_size;
> +
> + for (i = 0; i < num_queues; i++) {
> + vq = dev->virtqueue[i];
> + vq->inflight = (VhostInflightInfo *)rc;
> + rc = (void *)((char *)rc + pervq_inflight_size);
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> static int
> vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> }
>
> static int
> +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> +{
> + uint16_t i = 0;
> +
> + if ((!vq->inflight))
> + return RTE_VHOST_MSG_RESULT_ERR;
Should check whether the feature is negotiated first.
> +
> + if (!vq->inflight->version) {
> + vq->inflight->version = INFLIGHT_VERSION;
> + return RTE_VHOST_MSG_RESULT_OK;
> + }
> +
> + for (i = 0; i < vq->size; i++) {
> + if (vq->inflight->desc[i].inflight == 1) {
> + vq->inflight_flag = 1;
> + break;
> + }
> + }
> +
> + return RTE_VHOST_MSG_RESULT_OK;
> +}
> +
> +static int
> vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> int main_fd __rte_unused)
> {
> @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> close(vq->kickfd);
> vq->kickfd = file.fd;
>
> + if (vhost_check_queue_inflights(vq)) {
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "Failed to inflights for vq: %d\n", file.index);
> + return RTE_VHOST_MSG_RESULT_ERR;
> + }
> +
> return RTE_VHOST_MSG_RESULT_OK;
> }
>
> @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> };
>
>
> diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> index 2a650fe4b..35f969b1b 100644
> --- a/lib/librte_vhost/vhost_user.h
> +++ b/lib/librte_vhost/vhost_user.h
> @@ -23,7 +23,8 @@
> (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
It will advertise this feature for builtin net and crypto
backends. It's probably not what you intended.
>
> typedef enum VhostUserRequest {
> VHOST_USER_NONE = 0,
> @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> VHOST_USER_POSTCOPY_ADVISE = 28,
> VHOST_USER_POSTCOPY_LISTEN = 29,
> VHOST_USER_POSTCOPY_END = 30,
> - VHOST_USER_MAX = 31
> + VHOST_USER_GET_INFLIGHT_FD = 31,
> + VHOST_USER_SET_INFLIGHT_FD = 32,
> + VHOST_USER_MAX = 33
> } VhostUserRequest;
>
> typedef enum VhostUserSlaveRequest {
> @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> uint64_t offset;
> } VhostUserVringArea;
>
> +typedef struct VhostUserInflight {
> + uint64_t mmap_size;
> + uint64_t mmap_offset;
> + uint16_t num_queues;
> + uint16_t queue_size;
> +} VhostUserInflight;
> +
> typedef struct VhostUserMsg {
> union {
> uint32_t master; /* a VhostUserRequest value */
> @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> struct vhost_vring_addr addr;
> VhostUserMemory memory;
> VhostUserLog log;
> + VhostUserInflight inflight;
> struct vhost_iotlb_msg iotlb;
> VhostUserCryptoSessionParam crypto_session;
> VhostUserVringArea area;
> @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> /* vhost_user.c */
> int vhost_user_msg_handler(int vid, int fd);
> int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
>
> /* socket.c */
> int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> --
> 2.11.0
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
@ 2019-04-28 14:58 4% Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Arnon Warshavsky @ 2019-04-28 14:58 UTC (permalink / raw)
To: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare
Cc: arnonw, Arnon Warshavsky
For the purpose of removing instances of rte_panic
from the init sequence, some void functions need to change
to return an error code.The planned modifications of 19.08
require to change one eal function and one kni function.
Signed-off-by: Arnon Warshavsky <arnon@qwilt.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..c4ab9a2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,12 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_eal/common/eal_thread.h`` replace
+ ``void eal_thread_init_master(unsigned lcore_id)``
+ to return ``int``
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
@@ -65,6 +71,12 @@ Deprecation Notices
kernel modules in DPDK. As a result users won't be able to use ``ethtool``
via ``igb`` & ``ixgbe`` anymore.
+* kni: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_kni/rte_kni_fifo.h`` replace
+ ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
+ to return ``int``
+
* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
disable features supported by the crypto device. Only the following features
would be allowed to be disabled this way,
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
@ 2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Arnon Warshavsky @ 2019-04-28 14:58 UTC (permalink / raw)
To: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare
Cc: arnonw, Arnon Warshavsky
For the purpose of removing instances of rte_panic
from the init sequence, some void functions need to change
to return an error code.The planned modifications of 19.08
require to change one eal function and one kni function.
Signed-off-by: Arnon Warshavsky <arnon@qwilt.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..c4ab9a2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,12 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_eal/common/eal_thread.h`` replace
+ ``void eal_thread_init_master(unsigned lcore_id)``
+ to return ``int``
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
@@ -65,6 +71,12 @@ Deprecation Notices
kernel modules in DPDK. As a result users won't be able to use ``ethtool``
via ``igb`` & ``ixgbe`` anymore.
+* kni: Modify function return value for the sake of removing rte_panic
+ from the init sequence in version 19.08.
+ - In ``lib/librte_kni/rte_kni_fifo.h`` replace
+ ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
+ to return ``int``
+
* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
disable features supported by the crypto device. Only the following features
would be allowed to be disabled this way,
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
@ 2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-28 16:23 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Sun, 28 Apr 2019 17:58:48 +0300
Arnon Warshavsky <arnon@qwilt.com> wrote:
These deprecation notices are unnecessary. These are not public API's.
> +* eal: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_eal/common/eal_thread.h`` replace
> + ``void eal_thread_init_master(unsigned lcore_id)``
> + to return ``int``
This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
> +* kni: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> + to return ``int``
This is not a public API really so no deprecation needed.
It is just an include file used internally by library and the driver.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 16:23 4% ` Stephen Hemminger
@ 2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-28 16:23 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ferruh.yigit, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Sun, 28 Apr 2019 17:58:48 +0300
Arnon Warshavsky <arnon@qwilt.com> wrote:
These deprecation notices are unnecessary. These are not public API's.
> +* eal: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_eal/common/eal_thread.h`` replace
> + ``void eal_thread_init_master(unsigned lcore_id)``
> + to return ``int``
This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
> +* kni: Modify function return value for the sake of removing rte_panic
> + from the init sequence in version 19.08.
> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> + to return ``int``
This is not a public API really so no deprecation needed.
It is just an include file used internally by library and the driver.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
@ 2019-04-29 4:07 0% ` lin li
2019-04-29 4:07 0% ` lin li
1 sibling, 1 reply; 200+ results
From: lin li @ 2019-04-29 4:07 UTC (permalink / raw)
To: Tiwei Bie
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
Tiwei Bie <tiwei.bie@intel.com> 于2019年4月28日周日 下午7:18写道：
>
> On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> > From: lilin24 <lilin24@baidu.com>
> >
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> > and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> > buffer between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> > shared buffer from backend. Then qemu should send it back
> > through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
> >
> > Signed-off-by: lilin24 <lilin24@baidu.com>
>
> You need to use your real name here.
>
> > Signed-off-by: Ni Xun <nixun@baidu.com>
> > Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> >
> > v2:
> > - add set&clr inflight entry function
> > v3:
> > - simplified some function implementations
> >
> > ---
>
> You can put change logs here (i.e. after ---).
>
> > lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> > lib/librte_vhost/vhost.c | 42 ++++++++
> > lib/librte_vhost/vhost.h | 11 ++
> > lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 16 ++-
> > 5 files changed, 351 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index d2c0c93f4..bc25591a8 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -71,6 +71,10 @@ extern "C" {
> > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> > +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> > +#endif
> > +
> > /** Indicate whether protocol features negotiation is supported. */
> > #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> > #define VHOST_USER_F_PROTOCOL_FEATURES 30
> > @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> > struct rte_vhost_mem_region regions[];
> > };
> >
> > +typedef struct VhostUserInflightEntry {
> > + uint8_t inflight;
> > +} VhostUserInflightEntry;
> > +
> > +typedef struct VhostInflightInfo {
> > + uint16_t version;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + VhostUserInflightEntry desc[0];
> > +} VhostInflightInfo;
>
> Is there any details on above structure? Why does it not match
> QueueRegionSplit or QueueRegionPacked structures described in
> qemu/docs/interop/vhost-user.txt?
Qemu have its vhost-user backend，qemu did the submission of IO in it.
The implementation of dpdk is more general. It is just to mark inflight entry.
The submission of inflight entry is handle over to different backends.
They have their own ways to handle it, such as spdk.
So there are some differences in data structure.
>
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > struct vring_used *used;
> > uint64_t log_guest_addr;
> >
> > + VhostInflightInfo *inflight;
> > + int inflight_flag;
> > +
> > /** Deprecated, use rte_vhost_vring_call() instead. */
> > int callfd;
> >
> > @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > int rte_vhost_vring_call(int vid, uint16_t vring_idx);
> >
> > /**
> > + * set inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> > + uint16_t idx);
> > +
> > +/**
> > + * clear inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param last_used_idx
> > + * next free used_idx
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx);
> > +
> > +/**
> > + * set last inflight io index.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> > + uint16_t idx);
>
> New APIs should be experimental and also need to be
> added in rte_vhost_version.map file.
>
> > +
> > +/**
> > * Get vhost RX queue avail count.
> > *
> > * @param vid
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> > index 163f4595e..9ba692935 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> > close(vq->callfd);
> > if (vq->kickfd >= 0)
> > close(vq->kickfd);
> > + if (vq->inflight)
> > + vq->inflight = NULL;
> > }
> >
> > /*
> > @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > vring->kickfd = vq->kickfd;
> > vring->size = vq->size;
> >
> > + vring->inflight = vq->inflight;
> > +
> > + vring->inflight_flag = vq->inflight_flag;
> > + vq->inflight_flag = 0;
>
> This will break the ABI. Better to introduce a new API to do this.
>
> > +
> > return 0;
> > }
> >
> > @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> > return 0;
> > }
> >
> > +void
> > +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > + if (unlikely(!inflight))
> > + return;
> > + inflight->desc[idx].inflight = 1;
> > +}
> > +
> > +void
> > +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + rte_compiler_barrier();
> > + inflight->desc[idx].inflight = 0;
> > + rte_compiler_barrier();
> > + inflight->used_idx = last_used_idx;
> > +}
> > +
> > +void
> > +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + inflight->last_inflight_io = idx;
> > +}
>
> The rte_vhost_vring is used to return information to apps.
>
> IIUC, you want to update vq->inflight. So the rte_vhost_vring
> param should be replaced by vid + vring_idx.
>
> > +
> > uint16_t
> > rte_vhost_avail_entries(int vid, uint16_t queue_id)
> > {
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> > index e9138dfab..537d74c71 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> > /* Physical address of used ring, for logging */
> > uint64_t log_guest_addr;
> >
> > + /* Inflight share memory info */
> > + VhostInflightInfo *inflight;
> > + bool inflight_flag;
> > +
> > uint16_t nr_zmbuf;
> > uint16_t zmbuf_size;
> > uint16_t last_zmbuf_idx;
> > @@ -286,6 +290,12 @@ struct guest_page {
> > uint64_t size;
> > };
> >
> > +typedef struct VuDevInflightInfo {
> > + int fd;
> > + void *addr;
> > + uint64_t size;
> > +} VuDevInflightInfo;
>
> Please follow DPDK's coding style when defining internal structure.
>
> > +
> > /**
> > * Device structure contains all configuration information relating
> > * to the device.
> > @@ -303,6 +313,7 @@ struct virtio_net {
> > uint32_t nr_vring;
> > int dequeue_zero_copy;
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> > + VuDevInflightInfo inflight_info;
> > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> > char ifname[IF_NAME_SZ];
> > uint64_t log_size;
> > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> [...]
> > +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> > +{
> > + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> > + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> > +}
> > +
> > +static int
> > +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd;
> > + uint64_t mmap_size;
> > + void *addr;
> > + uint16_t num_queues, queue_size;
> > + struct virtio_net *dev = *pdev;
> > +
> > + if (msg->size != sizeof(msg->payload.inflight)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Invalid get_inflight_fd message size is %d",
> > + msg->size);
> > + msg->payload.inflight.mmap_size = 0;
>
> In this case, you can't touch the payload.
>
> > + return 0;
>
> And an error should be returned.
>
> > + }
> > +
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> > + msg->payload.inflight.num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> > + msg->payload.inflight.queue_size);
> > + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> > +
> > + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> > + if (!addr) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> > + msg->payload.inflight.mmap_size = 0;
> > + return 0;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > + memset(addr, 0, mmap_size);
> > +
> > + dev->inflight_info.addr = addr;
> > + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> > + dev->inflight_info.fd = msg->fds[0] = fd;
> > + msg->payload.inflight.mmap_offset = 0;
> > + msg->fd_num = 1;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_size: %lu\n",
> > + msg->payload.inflight.mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_offset: %lu\n",
> > + msg->payload.inflight.mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight fd: %d\n", msg->fds[0]);
> > +
> > + return RTE_VHOST_MSG_RESULT_REPLY;
> > +}
> > +
> > +static int
> > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd, i;
> > + uint64_t mmap_size, mmap_offset;
> > + uint16_t num_queues, queue_size;
> > + uint32_t pervq_inflight_size;
> > + void *rc;
> > + struct vhost_virtqueue *vq;
> > + struct virtio_net *dev = *pdev;
> > +
> > + fd = msg->fds[0];
> > + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> > + msg->size, fd);
> > + return -1;
>
> Ditto.
>
> > + }
> > +
> > + mmap_size = msg->payload.inflight.mmap_size;
> > + mmap_offset = msg->payload.inflight.mmap_offset;
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > + pervq_inflight_size = get_pervq_shm_size(queue_size);
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd num_queues: %u\n", num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd queue_size: %u\n", queue_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd fd: %d\n", fd);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd pervq_inflight_size: %d\n",
> > + pervq_inflight_size);
> > +
> > + if (dev->inflight_info.addr)
> > + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> > +
> > + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> > + fd, mmap_offset);
>
> Why call it rc? Maybe addr is a better name?
In some scenarios, shared memory is reallocated or resized by qemu, so
again mmap is needed.
>
> > + if (rc == MAP_FAILED) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> > + return -1;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > +
> > + if (dev->inflight_info.fd)
> > + close(dev->inflight_info.fd);
> > +
> > + dev->inflight_info.fd = fd;
> > + dev->inflight_info.addr = rc;
> > + dev->inflight_info.size = mmap_size;
> > +
> > + for (i = 0; i < num_queues; i++) {
> > + vq = dev->virtqueue[i];
> > + vq->inflight = (VhostInflightInfo *)rc;
> > + rc = (void *)((char *)rc + pervq_inflight_size);
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > static int
> > vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> > }
> >
> > static int
> > +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> > +{
> > + uint16_t i = 0;
> > +
> > + if ((!vq->inflight))
> > + return RTE_VHOST_MSG_RESULT_ERR;
>
> Should check whether the feature is negotiated first.
>
> > +
> > + if (!vq->inflight->version) {
> > + vq->inflight->version = INFLIGHT_VERSION;
> > + return RTE_VHOST_MSG_RESULT_OK;
> > + }
> > +
> > + for (i = 0; i < vq->size; i++) {
> > + if (vq->inflight->desc[i].inflight == 1) {
> > + vq->inflight_flag = 1;
> > + break;
> > + }
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > +static int
> > vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > {
> > @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > close(vq->kickfd);
> > vq->kickfd = file.fd;
> >
> > + if (vhost_check_queue_inflights(vq)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Failed to inflights for vq: %d\n", file.index);
> > + return RTE_VHOST_MSG_RESULT_ERR;
> > + }
> > +
> > return RTE_VHOST_MSG_RESULT_OK;
> > }
> >
> > @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> > [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> > [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> > [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> > + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> > + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> > };
> >
> >
> > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> > index 2a650fe4b..35f969b1b 100644
> > --- a/lib/librte_vhost/vhost_user.h
> > +++ b/lib/librte_vhost/vhost_user.h
> > @@ -23,7 +23,8 @@
> > (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> > - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> > + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> > + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
>
> It will advertise this feature for builtin net and crypto
> backends. It's probably not what you intended.
>
Indeed, this feature is mainly used for spdk-like backends. You mean
this function is disabled by default？
> >
> > typedef enum VhostUserRequest {
> > VHOST_USER_NONE = 0,
> > @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> > VHOST_USER_POSTCOPY_ADVISE = 28,
> > VHOST_USER_POSTCOPY_LISTEN = 29,
> > VHOST_USER_POSTCOPY_END = 30,
> > - VHOST_USER_MAX = 31
> > + VHOST_USER_GET_INFLIGHT_FD = 31,
> > + VHOST_USER_SET_INFLIGHT_FD = 32,
> > + VHOST_USER_MAX = 33
> > } VhostUserRequest;
> >
> > typedef enum VhostUserSlaveRequest {
> > @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> > uint64_t offset;
> > } VhostUserVringArea;
> >
> > +typedef struct VhostUserInflight {
> > + uint64_t mmap_size;
> > + uint64_t mmap_offset;
> > + uint16_t num_queues;
> > + uint16_t queue_size;
> > +} VhostUserInflight;
> > +
> > typedef struct VhostUserMsg {
> > union {
> > uint32_t master; /* a VhostUserRequest value */
> > @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> > struct vhost_vring_addr addr;
> > VhostUserMemory memory;
> > VhostUserLog log;
> > + VhostUserInflight inflight;
> > struct vhost_iotlb_msg iotlb;
> > VhostUserCryptoSessionParam crypto_session;
> > VhostUserVringArea area;
> > @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> > /* vhost_user.c */
> > int vhost_user_msg_handler(int vid, int fd);
> > int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> > +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
> >
> > /* socket.c */
> > int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> > --
> > 2.11.0
> >
Thank you for your comments. They will be revised in the next version.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] vhost: support inflight share memory protocol feature
2019-04-29 4:07 0% ` lin li
@ 2019-04-29 4:07 0% ` lin li
0 siblings, 0 replies; 200+ results
From: lin li @ 2019-04-29 4:07 UTC (permalink / raw)
To: Tiwei Bie
Cc: maxime.coquelin, zhihong.wang, dev, dariusz.stojaczyk,
changpeng.liu, james.r.harris, lilin24, Ni Xun, Zhang Yu
Tiwei Bie <tiwei.bie@intel.com> 于2019年4月28日周日 下午7:18写道：
>
> On Fri, Apr 26, 2019 at 05:40:21AM -0400, Li Lin wrote:
> > From: lilin24 <lilin24@baidu.com>
> >
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> > and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> > buffer between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> > shared buffer from backend. Then qemu should send it back
> > through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
> >
> > Signed-off-by: lilin24 <lilin24@baidu.com>
>
> You need to use your real name here.
>
> > Signed-off-by: Ni Xun <nixun@baidu.com>
> > Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> >
> > v2:
> > - add set&clr inflight entry function
> > v3:
> > - simplified some function implementations
> >
> > ---
>
> You can put change logs here (i.e. after ---).
>
> > lib/librte_vhost/rte_vhost.h | 53 ++++++++++
> > lib/librte_vhost/vhost.c | 42 ++++++++
> > lib/librte_vhost/vhost.h | 11 ++
> > lib/librte_vhost/vhost_user.c | 231 ++++++++++++++++++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 16 ++-
> > 5 files changed, 351 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index d2c0c93f4..bc25591a8 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -71,6 +71,10 @@ extern "C" {
> > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> > +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> > +#endif
> > +
> > /** Indicate whether protocol features negotiation is supported. */
> > #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> > #define VHOST_USER_F_PROTOCOL_FEATURES 30
> > @@ -98,12 +102,26 @@ struct rte_vhost_memory {
> > struct rte_vhost_mem_region regions[];
> > };
> >
> > +typedef struct VhostUserInflightEntry {
> > + uint8_t inflight;
> > +} VhostUserInflightEntry;
> > +
> > +typedef struct VhostInflightInfo {
> > + uint16_t version;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + VhostUserInflightEntry desc[0];
> > +} VhostInflightInfo;
>
> Is there any details on above structure? Why does it not match
> QueueRegionSplit or QueueRegionPacked structures described in
> qemu/docs/interop/vhost-user.txt?
Qemu have its vhost-user backend，qemu did the submission of IO in it.
The implementation of dpdk is more general. It is just to mark inflight entry.
The submission of inflight entry is handle over to different backends.
They have their own ways to handle it, such as spdk.
So there are some differences in data structure.
>
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > struct vring_used *used;
> > uint64_t log_guest_addr;
> >
> > + VhostInflightInfo *inflight;
> > + int inflight_flag;
> > +
> > /** Deprecated, use rte_vhost_vring_call() instead. */
> > int callfd;
> >
> > @@ -632,6 +650,41 @@ int rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > int rte_vhost_vring_call(int vid, uint16_t vring_idx);
> >
> > /**
> > + * set inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_inflight(struct rte_vhost_vring *vring,
> > + uint16_t idx);
> > +
> > +/**
> > + * clear inflight flag for a entry.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param last_used_idx
> > + * next free used_idx
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx);
> > +
> > +/**
> > + * set last inflight io index.
> > + *
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @param idx
> > + * inflight entry index
> > + */
> > +void rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring,
> > + uint16_t idx);
>
> New APIs should be experimental and also need to be
> added in rte_vhost_version.map file.
>
> > +
> > +/**
> > * Get vhost RX queue avail count.
> > *
> > * @param vid
> > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
> > index 163f4595e..9ba692935 100644
> > --- a/lib/librte_vhost/vhost.c
> > +++ b/lib/librte_vhost/vhost.c
> > @@ -76,6 +76,8 @@ cleanup_vq(struct vhost_virtqueue *vq, int destroy)
> > close(vq->callfd);
> > if (vq->kickfd >= 0)
> > close(vq->kickfd);
> > + if (vq->inflight)
> > + vq->inflight = NULL;
> > }
> >
> > /*
> > @@ -589,6 +591,11 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
> > vring->kickfd = vq->kickfd;
> > vring->size = vq->size;
> >
> > + vring->inflight = vq->inflight;
> > +
> > + vring->inflight_flag = vq->inflight_flag;
> > + vq->inflight_flag = 0;
>
> This will break the ABI. Better to introduce a new API to do this.
>
> > +
> > return 0;
> > }
> >
> > @@ -617,6 +624,41 @@ rte_vhost_vring_call(int vid, uint16_t vring_idx)
> > return 0;
> > }
> >
> > +void
> > +rte_vhost_set_inflight(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > + if (unlikely(!inflight))
> > + return;
> > + inflight->desc[idx].inflight = 1;
> > +}
> > +
> > +void
> > +rte_vhost_clr_inflight(struct rte_vhost_vring *vring,
> > + uint16_t last_used_idx, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + rte_compiler_barrier();
> > + inflight->desc[idx].inflight = 0;
> > + rte_compiler_barrier();
> > + inflight->used_idx = last_used_idx;
> > +}
> > +
> > +void
> > +rte_vhost_set_last_inflight_io(struct rte_vhost_vring *vring, uint16_t idx)
> > +{
> > + VhostInflightInfo *inflight = vring->inflight;
> > +
> > + if (unlikely(!inflight))
> > + return;
> > +
> > + inflight->last_inflight_io = idx;
> > +}
>
> The rte_vhost_vring is used to return information to apps.
>
> IIUC, you want to update vq->inflight. So the rte_vhost_vring
> param should be replaced by vid + vring_idx.
>
> > +
> > uint16_t
> > rte_vhost_avail_entries(int vid, uint16_t queue_id)
> > {
> > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
> > index e9138dfab..537d74c71 100644
> > --- a/lib/librte_vhost/vhost.h
> > +++ b/lib/librte_vhost/vhost.h
> > @@ -128,6 +128,10 @@ struct vhost_virtqueue {
> > /* Physical address of used ring, for logging */
> > uint64_t log_guest_addr;
> >
> > + /* Inflight share memory info */
> > + VhostInflightInfo *inflight;
> > + bool inflight_flag;
> > +
> > uint16_t nr_zmbuf;
> > uint16_t zmbuf_size;
> > uint16_t last_zmbuf_idx;
> > @@ -286,6 +290,12 @@ struct guest_page {
> > uint64_t size;
> > };
> >
> > +typedef struct VuDevInflightInfo {
> > + int fd;
> > + void *addr;
> > + uint64_t size;
> > +} VuDevInflightInfo;
>
> Please follow DPDK's coding style when defining internal structure.
>
> > +
> > /**
> > * Device structure contains all configuration information relating
> > * to the device.
> > @@ -303,6 +313,7 @@ struct virtio_net {
> > uint32_t nr_vring;
> > int dequeue_zero_copy;
> > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2];
> > + VuDevInflightInfo inflight_info;
> > #define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
> > char ifname[IF_NAME_SZ];
> > uint64_t log_size;
> > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
> [...]
> > +static uint32_t get_pervq_shm_size(uint16_t queue_size)
> > +{
> > + return ALIGN_UP(sizeof(VhostUserInflightEntry) * queue_size +
> > + sizeof(uint16_t) * 3, INFLIGHT_ALIGNMENT);
> > +}
> > +
> > +static int
> > +vhost_user_get_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd;
> > + uint64_t mmap_size;
> > + void *addr;
> > + uint16_t num_queues, queue_size;
> > + struct virtio_net *dev = *pdev;
> > +
> > + if (msg->size != sizeof(msg->payload.inflight)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Invalid get_inflight_fd message size is %d",
> > + msg->size);
> > + msg->payload.inflight.mmap_size = 0;
>
> In this case, you can't touch the payload.
>
> > + return 0;
>
> And an error should be returned.
>
> > + }
> > +
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd num_queues: %u\n",
> > + msg->payload.inflight.num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG, "get_inflight_fd queue_size: %u\n",
> > + msg->payload.inflight.queue_size);
> > + mmap_size = num_queues * get_pervq_shm_size(queue_size);
> > +
> > + addr = inflight_mem_alloc("vhost-inflight", mmap_size, &fd);
> > + if (!addr) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Failed to alloc vhost inflight area");
> > + msg->payload.inflight.mmap_size = 0;
> > + return 0;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > + memset(addr, 0, mmap_size);
> > +
> > + dev->inflight_info.addr = addr;
> > + dev->inflight_info.size = msg->payload.inflight.mmap_size = mmap_size;
> > + dev->inflight_info.fd = msg->fds[0] = fd;
> > + msg->payload.inflight.mmap_offset = 0;
> > + msg->fd_num = 1;
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_size: %lu\n",
> > + msg->payload.inflight.mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight mmap_offset: %lu\n",
> > + msg->payload.inflight.mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "send inflight fd: %d\n", msg->fds[0]);
> > +
> > + return RTE_VHOST_MSG_RESULT_REPLY;
> > +}
> > +
> > +static int
> > +vhost_user_set_inflight_fd(struct virtio_net **pdev, VhostUserMsg *msg,
> > + int main_fd __rte_unused)
> > +{
> > + int fd, i;
> > + uint64_t mmap_size, mmap_offset;
> > + uint16_t num_queues, queue_size;
> > + uint32_t pervq_inflight_size;
> > + void *rc;
> > + struct vhost_virtqueue *vq;
> > + struct virtio_net *dev = *pdev;
> > +
> > + fd = msg->fds[0];
> > + if (msg->size != sizeof(msg->payload.inflight) || fd < 0) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "Invalid set_inflight_fd message size is %d,fd is %d\n",
> > + msg->size, fd);
> > + return -1;
>
> Ditto.
>
> > + }
> > +
> > + mmap_size = msg->payload.inflight.mmap_size;
> > + mmap_offset = msg->payload.inflight.mmap_offset;
> > + num_queues = msg->payload.inflight.num_queues;
> > + queue_size = msg->payload.inflight.queue_size;
> > + pervq_inflight_size = get_pervq_shm_size(queue_size);
> > +
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_size: %lu\n", mmap_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd mmap_offset: %lu\n", mmap_offset);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd num_queues: %u\n", num_queues);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd queue_size: %u\n", queue_size);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd fd: %d\n", fd);
> > + RTE_LOG(INFO, VHOST_CONFIG,
> > + "set_inflight_fd pervq_inflight_size: %d\n",
> > + pervq_inflight_size);
> > +
> > + if (dev->inflight_info.addr)
> > + munmap(dev->inflight_info.addr, dev->inflight_info.size);
> > +
> > + rc = mmap(0, mmap_size, PROT_READ | PROT_WRITE, MAP_SHARED,
> > + fd, mmap_offset);
>
> Why call it rc? Maybe addr is a better name?
In some scenarios, shared memory is reallocated or resized by qemu, so
again mmap is needed.
>
> > + if (rc == MAP_FAILED) {
> > + RTE_LOG(ERR, VHOST_CONFIG, "failed to mmap share memory.\n");
> > + return -1;
>
> Should always return RTE_VHOST_MSG_RESULT_* in
> message handler.
>
> > + }
> > +
> > + if (dev->inflight_info.fd)
> > + close(dev->inflight_info.fd);
> > +
> > + dev->inflight_info.fd = fd;
> > + dev->inflight_info.addr = rc;
> > + dev->inflight_info.size = mmap_size;
> > +
> > + for (i = 0; i < num_queues; i++) {
> > + vq = dev->virtqueue[i];
> > + vq->inflight = (VhostInflightInfo *)rc;
> > + rc = (void *)((char *)rc + pervq_inflight_size);
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > static int
> > vhost_user_set_vring_call(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > @@ -1202,6 +1402,29 @@ static int vhost_user_set_vring_err(struct virtio_net **pdev __rte_unused,
> > }
> >
> > static int
> > +vhost_check_queue_inflights(struct vhost_virtqueue *vq)
> > +{
> > + uint16_t i = 0;
> > +
> > + if ((!vq->inflight))
> > + return RTE_VHOST_MSG_RESULT_ERR;
>
> Should check whether the feature is negotiated first.
>
> > +
> > + if (!vq->inflight->version) {
> > + vq->inflight->version = INFLIGHT_VERSION;
> > + return RTE_VHOST_MSG_RESULT_OK;
> > + }
> > +
> > + for (i = 0; i < vq->size; i++) {
> > + if (vq->inflight->desc[i].inflight == 1) {
> > + vq->inflight_flag = 1;
> > + break;
> > + }
> > + }
> > +
> > + return RTE_VHOST_MSG_RESULT_OK;
> > +}
> > +
> > +static int
> > vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > int main_fd __rte_unused)
> > {
> > @@ -1242,6 +1465,12 @@ vhost_user_set_vring_kick(struct virtio_net **pdev, struct VhostUserMsg *msg,
> > close(vq->kickfd);
> > vq->kickfd = file.fd;
> >
> > + if (vhost_check_queue_inflights(vq)) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "Failed to inflights for vq: %d\n", file.index);
> > + return RTE_VHOST_MSG_RESULT_ERR;
> > + }
> > +
> > return RTE_VHOST_MSG_RESULT_OK;
> > }
> >
> > @@ -1762,6 +1991,8 @@ static vhost_message_handler_t vhost_message_handlers[VHOST_USER_MAX] = {
> > [VHOST_USER_POSTCOPY_ADVISE] = vhost_user_set_postcopy_advise,
> > [VHOST_USER_POSTCOPY_LISTEN] = vhost_user_set_postcopy_listen,
> > [VHOST_USER_POSTCOPY_END] = vhost_user_postcopy_end,
> > + [VHOST_USER_GET_INFLIGHT_FD] = vhost_user_get_inflight_fd,
> > + [VHOST_USER_SET_INFLIGHT_FD] = vhost_user_set_inflight_fd,
> > };
> >
> >
> > diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
> > index 2a650fe4b..35f969b1b 100644
> > --- a/lib/librte_vhost/vhost_user.h
> > +++ b/lib/librte_vhost/vhost_user.h
> > @@ -23,7 +23,8 @@
> > (1ULL << VHOST_USER_PROTOCOL_F_CRYPTO_SESSION) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD) | \
> > (1ULL << VHOST_USER_PROTOCOL_F_HOST_NOTIFIER) | \
> > - (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT))
> > + (1ULL << VHOST_USER_PROTOCOL_F_PAGEFAULT) | \
> > + (1ULL << VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD))
>
> It will advertise this feature for builtin net and crypto
> backends. It's probably not what you intended.
>
Indeed, this feature is mainly used for spdk-like backends. You mean
this function is disabled by default？
> >
> > typedef enum VhostUserRequest {
> > VHOST_USER_NONE = 0,
> > @@ -54,7 +55,9 @@ typedef enum VhostUserRequest {
> > VHOST_USER_POSTCOPY_ADVISE = 28,
> > VHOST_USER_POSTCOPY_LISTEN = 29,
> > VHOST_USER_POSTCOPY_END = 30,
> > - VHOST_USER_MAX = 31
> > + VHOST_USER_GET_INFLIGHT_FD = 31,
> > + VHOST_USER_SET_INFLIGHT_FD = 32,
> > + VHOST_USER_MAX = 33
> > } VhostUserRequest;
> >
> > typedef enum VhostUserSlaveRequest {
> > @@ -112,6 +115,13 @@ typedef struct VhostUserVringArea {
> > uint64_t offset;
> > } VhostUserVringArea;
> >
> > +typedef struct VhostUserInflight {
> > + uint64_t mmap_size;
> > + uint64_t mmap_offset;
> > + uint16_t num_queues;
> > + uint16_t queue_size;
> > +} VhostUserInflight;
> > +
> > typedef struct VhostUserMsg {
> > union {
> > uint32_t master; /* a VhostUserRequest value */
> > @@ -131,6 +141,7 @@ typedef struct VhostUserMsg {
> > struct vhost_vring_addr addr;
> > VhostUserMemory memory;
> > VhostUserLog log;
> > + VhostUserInflight inflight;
> > struct vhost_iotlb_msg iotlb;
> > VhostUserCryptoSessionParam crypto_session;
> > VhostUserVringArea area;
> > @@ -148,6 +159,7 @@ typedef struct VhostUserMsg {
> > /* vhost_user.c */
> > int vhost_user_msg_handler(int vid, int fd);
> > int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
> > +void *inflight_mem_alloc(const char *name, size_t size, int *fd);
> >
> > /* socket.c */
> > int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
> > --
> > 2.11.0
> >
Thank you for your comments. They will be revised in the next version.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
@ 2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 9:28 UTC (permalink / raw)
To: Stephen Hemminger, Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ranjit.menon, anand.rawat,
pallavi.kadam, harini.ramakrishnan, cathal.ohare, arnonw
On 4/28/2019 5:23 PM, Stephen Hemminger wrote:
> On Sun, 28 Apr 2019 17:58:48 +0300
> Arnon Warshavsky <arnon@qwilt.com> wrote:
>
> These deprecation notices are unnecessary. These are not public API's.
+1
>
>> +* eal: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_eal/common/eal_thread.h`` replace
>> + ``void eal_thread_init_master(unsigned lcore_id)``
>> + to return ``int``
>
> This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
>
>
>> +* kni: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>> + to return ``int``
>
> This is not a public API really so no deprecation needed.
> It is just an include file used internally by library and the driver.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 9:28 4% ` Ferruh Yigit
@ 2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 9:28 UTC (permalink / raw)
To: Stephen Hemminger, Arnon Warshavsky
Cc: dev, thomas, anatoly.burakov, wenzhuo.lu, declan.doherty,
jerin.jacob, bruce.richardson, ranjit.menon, anand.rawat,
pallavi.kadam, harini.ramakrishnan, cathal.ohare, arnonw
On 4/28/2019 5:23 PM, Stephen Hemminger wrote:
> On Sun, 28 Apr 2019 17:58:48 +0300
> Arnon Warshavsky <arnon@qwilt.com> wrote:
>
> These deprecation notices are unnecessary. These are not public API's.
+1
>
>> +* eal: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_eal/common/eal_thread.h`` replace
>> + ``void eal_thread_init_master(unsigned lcore_id)``
>> + to return ``int``
>
> This function is never exported (see rte_eal_version.map) and therefore be marked private to the EAL, and not a public API.
>
>
>> +* kni: Modify function return value for the sake of removing rte_panic
>> + from the init sequence in version 19.08.
>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>> + to return ``int``
>
> This is not a public API really so no deprecation needed.
> It is just an include file used internally by library and the driver.
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
@ 2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-04-29 16:24 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Mon, 29 Apr 2019 10:28:36 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> >
> >> +* kni: Modify function return value for the sake of removing rte_panic
> >> + from the init sequence in version 19.08.
> >> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> >> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> >> + to return ``int``
> >
> > This is not a public API really so no deprecation needed.
> > It is just an include file used internally by library and the driver.
> >
This does introduce the possibility of kernel/library version mismatch.
You might want to add a magic number to shared data structure.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 16:24 4% ` Stephen Hemminger
@ 2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-29 16:24 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On Mon, 29 Apr 2019 10:28:36 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >
> >
> >> +* kni: Modify function return value for the sake of removing rte_panic
> >> + from the init sequence in version 19.08.
> >> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
> >> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
> >> + to return ``int``
> >
> > This is not a public API really so no deprecation needed.
> > It is just an include file used internally by library and the driver.
> >
This does introduce the possibility of kernel/library version mismatch.
You might want to add a magic number to shared data structure.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
@ 2019-04-29 17:19 4% ` Ferruh Yigit
2019-04-29 17:19 4% ` Ferruh Yigit
2019-05-07 9:57 4% ` Arnon Warshavsky
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 17:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On 4/29/2019 5:24 PM, Stephen Hemminger wrote:
> On Mon, 29 Apr 2019 10:28:36 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
>>>
>>>
>>>> +* kni: Modify function return value for the sake of removing rte_panic
>>>> + from the init sequence in version 19.08.
>>>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>>>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>>>> + to return ``int``
>>>
>>> This is not a public API really so no deprecation needed.
>>> It is just an include file used internally by library and the driver.
>>>
>
> This does introduce the possibility of kernel/library version mismatch.
> You might want to add a magic number to shared data structure.
>
Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
perhaps it would be a problem if the content of the fifo changed but it is not
the case.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 17:19 4% ` Ferruh Yigit
@ 2019-04-29 17:19 4% ` Ferruh Yigit
2019-05-07 9:57 4% ` Arnon Warshavsky
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-29 17:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Arnon Warshavsky, dev, thomas, anatoly.burakov, wenzhuo.lu,
declan.doherty, jerin.jacob, bruce.richardson, ranjit.menon,
anand.rawat, pallavi.kadam, harini.ramakrishnan, cathal.ohare,
arnonw
On 4/29/2019 5:24 PM, Stephen Hemminger wrote:
> On Mon, 29 Apr 2019 10:28:36 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
>>>
>>>
>>>> +* kni: Modify function return value for the sake of removing rte_panic
>>>> + from the init sequence in version 19.08.
>>>> + - In ``lib/librte_kni/rte_kni_fifo.h`` replace
>>>> + ``static void kni_fifo_init(struct rte_kni_fifo *fifo, unsigned size)``
>>>> + to return ``int``
>>>
>>> This is not a public API really so no deprecation needed.
>>> It is just an include file used internally by library and the driver.
>>>
>
> This does introduce the possibility of kernel/library version mismatch.
> You might want to add a magic number to shared data structure.
>
Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
perhaps it would be a problem if the content of the fifo changed but it is not
the case.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:54 4% ` Burakov, Anatoly
@ 2019-04-30 8:52 9% ` Thomas Monjalon
2019-04-30 8:52 9% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-04-30 8:52 UTC (permalink / raw)
To: dev
Cc: Ray Kinsella, Burakov, Anatoly, Bruce Richardson,
Honnappa Nagarahalli, Stephen Hemminger, Ananyev, Konstantin, nd
24/04/2019 14:22, Ray Kinsella:
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
> > To me, part of the problem is that DPDK is an "everything and the
> > kitchen sink" kind of library where there is a bunch of drivers, a whole
> > quasi-OS layer of dealing with hardware in a cross-platform manner, a
> > separate memory management system, a bunch of libraries such as hash/lpm
> > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> > library" would concentrate on doing one thing well. DPDK, on the other
> > hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> > is, i think, contributing to the breakages. If you keep 99% of your
> > libraries stable between version, but there's a small ABI tweak in an
> > LPM library, the entire DPDK stability gets invalidated.
Yes, that's why we keep the split in libraries.
So we can update LPM library version while keeping the same ethdev
version to allow applications to load the shared library of the same
name without any re-compilation. In this case, the need for
re-compilation is only for applications using LPM.
But this model is not convenient for distributions because they
manage DPDK as one package. It means they have to re-compile all
applications if one LPM ABI is broken, even if it is experimental.
Should the libraries be split in packages?
> Well I guess DPDK is no more complex than Java or .NET Framework in that
> respect, as these also feature OS-layers, memory management systems,
> application frameworks, primitives etc but do manage to give their
> consumers strong guarantee's on API stability. Clearly ABI stability has
> a no meaning when you always being JIT compiled.
>
> I understand that doing everything right the first time, allowing for
> future evolution, while keep ABI/APIs relatively stable is a tough ask.
>
> I would propose that API's marked as "experimental" be given greater
> freedom to change to give time of API's to bake, so they don't need to
> be always "right first time", that there is wriggle room for these.
As said above, experimental level does not solve ABI stability.
If we break an experimental API, the ABI is broken, requiring
to re-compile the application.
> I would also propose more use of ABI Versioning to enable evolution of
> DPDK while preserving backward compatibility.
Yes, if all other obvious versioning issues are solved,
we can walk the extra mile of better using ABI versioning.
> > Perhaps limiting DPDK's scope would help with this as well.
>
> I agree.
Yes, either split the project in more limited scope areas,
or split the packages.
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] ABI and inline functions
2019-04-30 8:52 9% ` Thomas Monjalon
@ 2019-04-30 8:52 9% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-04-30 8:52 UTC (permalink / raw)
To: dev
Cc: Ray Kinsella, Burakov, Anatoly, Bruce Richardson,
Honnappa Nagarahalli, Stephen Hemminger, Ananyev, Konstantin, nd
24/04/2019 14:22, Ray Kinsella:
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
> > To me, part of the problem is that DPDK is an "everything and the
> > kitchen sink" kind of library where there is a bunch of drivers, a whole
> > quasi-OS layer of dealing with hardware in a cross-platform manner, a
> > separate memory management system, a bunch of libraries such as hash/lpm
> > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> > library" would concentrate on doing one thing well. DPDK, on the other
> > hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> > is, i think, contributing to the breakages. If you keep 99% of your
> > libraries stable between version, but there's a small ABI tweak in an
> > LPM library, the entire DPDK stability gets invalidated.
Yes, that's why we keep the split in libraries.
So we can update LPM library version while keeping the same ethdev
version to allow applications to load the shared library of the same
name without any re-compilation. In this case, the need for
re-compilation is only for applications using LPM.
But this model is not convenient for distributions because they
manage DPDK as one package. It means they have to re-compile all
applications if one LPM ABI is broken, even if it is experimental.
Should the libraries be split in packages?
> Well I guess DPDK is no more complex than Java or .NET Framework in that
> respect, as these also feature OS-layers, memory management systems,
> application frameworks, primitives etc but do manage to give their
> consumers strong guarantee's on API stability. Clearly ABI stability has
> a no meaning when you always being JIT compiled.
>
> I understand that doing everything right the first time, allowing for
> future evolution, while keep ABI/APIs relatively stable is a tough ask.
>
> I would propose that API's marked as "experimental" be given greater
> freedom to change to give time of API's to bake, so they don't need to
> be always "right first time", that there is wriggle room for these.
As said above, experimental level does not solve ABI stability.
If we break an experimental API, the ABI is broken, requiring
to re-compile the application.
> I would also propose more use of ABI Versioning to enable evolution of
> DPDK while preserving backward compatibility.
Yes, if all other obvious versioning issues are solved,
we can walk the extra mile of better using ABI versioning.
> > Perhaps limiting DPDK's scope would help with this as well.
>
> I agree.
Yes, either split the project in more limited scope areas,
or split the packages.
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:08 4% ` Neil Horman
@ 2019-05-01 23:47 4% ` Thomas Monjalon
2019-05-01 23:47 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-05-01 23:47 UTC (permalink / raw)
To: Peng Huang; +Cc: dev, Neil Horman, qi.z.zhang, qiming.yang, wenzhuo.lu, stable
24/04/2019 14:08, Neil Horman:
> On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> > The new default-taget "linux" is introduced in v19.05-rc1
> > but not exist in before release such as v19.02 which have
> > default-target "linuxapp", there is no compatibility report
> > when run validate-abi.sh to check ABI compatibility between
> > v19.05-rc1 and v19.02, changed default-target from "linux"
> > to "linuxapp" in validate-abi.sh
> >
> > Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Peng Huang <peng.huang@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks and welcome!
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking
2019-05-01 23:47 4% ` Thomas Monjalon
@ 2019-05-01 23:47 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-01 23:47 UTC (permalink / raw)
To: Peng Huang; +Cc: dev, Neil Horman, qi.z.zhang, qiming.yang, wenzhuo.lu, stable
24/04/2019 14:08, Neil Horman:
> On Wed, Apr 24, 2019 at 03:11:59PM +0000, Peng Huang wrote:
> > The new default-taget "linux" is introduced in v19.05-rc1
> > but not exist in before release such as v19.02 which have
> > default-target "linuxapp", there is no compatibility report
> > when run validate-abi.sh to check ABI compatibility between
> > v19.05-rc1 and v19.02, changed default-target from "linux"
> > to "linuxapp" in validate-abi.sh
> >
> > Fixes: 218c4e68c1d9 ("mk: use linux and freebsd in config names")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Peng Huang <peng.huang@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks and welcome!
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
@ 2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
0 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-02 15:53 UTC (permalink / raw)
To: Reshma Pattan, dev; +Cc: david.marchand, bruce.richardson
On 02-May-19 3:13 PM, Reshma Pattan wrote:
> gcc 9 on Fedora 30 gives an error
> "taking address of packed member may result in an
> unaligned pointer value" for -Waddress-of-packed-member.
>
> Report it as warning instead of error to fix the build.
>
> Snippet of build before fix
> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> 768 | cur_msl = &mcfg->memsegs[msl_idx];
> | ^~~~~~~~~~~~~~~~~~~~~~~
>
> Snippet of build after fix
> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Waddress-of-packed-member]
> 685 | msl = &mcfg->memsegs[msl_idx];
>
Fixing these would require an ABI break, because these are exposed
externally. Should we submit a deprecation notice for EAL?
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 15:53 3% ` Burakov, Anatoly
@ 2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-02 15:53 UTC (permalink / raw)
To: Reshma Pattan, dev; +Cc: david.marchand, bruce.richardson
On 02-May-19 3:13 PM, Reshma Pattan wrote:
> gcc 9 on Fedora 30 gives an error
> "taking address of packed member may result in an
> unaligned pointer value" for -Waddress-of-packed-member.
>
> Report it as warning instead of error to fix the build.
>
> Snippet of build before fix
> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> 768 | cur_msl = &mcfg->memsegs[msl_idx];
> | ^~~~~~~~~~~~~~~~~~~~~~~
>
> Snippet of build after fix
> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> of packed member of ‘struct rte_mem_config’ may result in an unaligned
> pointer value [-Waddress-of-packed-member]
> 685 | msl = &mcfg->memsegs[msl_idx];
>
Fixing these would require an ABI break, because these are exposed
externally. Should we submit a deprecation notice for EAL?
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
@ 2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 18:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On Thu, 2 May 2019 16:53:50 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 02-May-19 3:13 PM, Reshma Pattan wrote:
> > gcc 9 on Fedora 30 gives an error
> > "taking address of packed member may result in an
> > unaligned pointer value" for -Waddress-of-packed-member.
> >
> > Report it as warning instead of error to fix the build.
> >
> > Snippet of build before fix
> > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Werror=address-of-packed-member]
> > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Snippet of build after fix
> > ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> > ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Waddress-of-packed-member]
> > 685 | msl = &mcfg->memsegs[msl_idx];
> >
>
> Fixing these would require an ABI break, because these are exposed
> externally. Should we submit a deprecation notice for EAL?
Ideally mem config and related structures would not be exposed in the
API. Like lcore_config and eal_config it should be eal_private
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 18:54 0% ` Stephen Hemminger
@ 2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 18:54 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On Thu, 2 May 2019 16:53:50 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 02-May-19 3:13 PM, Reshma Pattan wrote:
> > gcc 9 on Fedora 30 gives an error
> > "taking address of packed member may result in an
> > unaligned pointer value" for -Waddress-of-packed-member.
> >
> > Report it as warning instead of error to fix the build.
> >
> > Snippet of build before fix
> > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Werror=address-of-packed-member]
> > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Snippet of build after fix
> > ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
> > ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
> > of packed member of ‘struct rte_mem_config’ may result in an unaligned
> > pointer value [-Waddress-of-packed-member]
> > 685 | msl = &mcfg->memsegs[msl_idx];
> >
>
> Fixing these would require an ABI break, because these are exposed
> externally. Should we submit a deprecation notice for EAL?
Ideally mem config and related structures would not be exposed in the
API. Like lcore_config and eal_config it should be eal_private
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
@ 2019-05-02 23:15 0% ` Stephen Hemminger
2019-05-02 23:15 0% ` Stephen Hemminger
2019-05-03 17:25 8% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-05-02 23:15 UTC (permalink / raw)
To: dev
On Wed, 10 Apr 2019 10:15:58 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> 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(-)
>
Why is this patchset still stuck in the queue?
The parts with deprecation and accessor functions should really go in 19.05
but since it has sat around for so long, it is probably too late.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/5] make lcore_config internal
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-05-02 23:15 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-02 23:15 UTC (permalink / raw)
To: dev
On Wed, 10 Apr 2019 10:15:58 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:
> 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(-)
>
Why is this patchset still stuck in the queue?
The parts with deprecation and accessor functions should really go in 19.05
but since it has sat around for so long, it is probably too late.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
@ 2019-05-03 7:22 0% ` David Marchand
2019-05-03 7:22 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-03 7:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Apr 10, 2019 at 7:16 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> 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);
>
This is new from v2.
Please remove this __rte_experimental tag.
> /**
> * 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;
> +
>
19.05 inherits from 18.11 not 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
>
And with these two changes, renewing my tag.
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config
2019-05-03 7:22 0% ` David Marchand
@ 2019-05-03 7:22 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 7:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Apr 10, 2019 at 7:16 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:
> 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);
>
This is new from v2.
Please remove this __rte_experimental tag.
> /**
> * 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;
> +
>
19.05 inherits from 18.11 not 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
>
And with these two changes, renewing my tag.
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
@ 2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-03 7:56 0% ` Burakov, Anatoly
1 sibling, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-05-03 7:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On 02-May-19 7:54 PM, Stephen Hemminger wrote:
> On Thu, 2 May 2019 16:53:50 +0100
> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
>
>> On 02-May-19 3:13 PM, Reshma Pattan wrote:
>>> gcc 9 on Fedora 30 gives an error
>>> "taking address of packed member may result in an
>>> unaligned pointer value" for -Waddress-of-packed-member.
>>>
>>> Report it as warning instead of error to fix the build.
>>>
>>> Snippet of build before fix
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>> 768 | cur_msl = &mcfg->memsegs[msl_idx];
>>> | ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Snippet of build after fix
>>> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
>>> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Waddress-of-packed-member]
>>> 685 | msl = &mcfg->memsegs[msl_idx];
>>>
>>
>> Fixing these would require an ABI break, because these are exposed
>> externally. Should we submit a deprecation notice for EAL?
>
>
> Ideally mem config and related structures would not be exposed in the
> API. Like lcore_config and eal_config it should be eal_private
>
In a perfect world, that would've been the case. However, these are in
shared memory structures that are used for multiprocess synchronization.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] mk: report address of packed member as warning
2019-05-03 7:56 0% ` Burakov, Anatoly
@ 2019-05-03 7:56 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-03 7:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Reshma Pattan, dev, david.marchand, bruce.richardson
On 02-May-19 7:54 PM, Stephen Hemminger wrote:
> On Thu, 2 May 2019 16:53:50 +0100
> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
>
>> On 02-May-19 3:13 PM, Reshma Pattan wrote:
>>> gcc 9 on Fedora 30 gives an error
>>> "taking address of packed member may result in an
>>> unaligned pointer value" for -Waddress-of-packed-member.
>>>
>>> Report it as warning instead of error to fix the build.
>>>
>>> Snippet of build before fix
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
>>> ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>> 768 | cur_msl = &mcfg->memsegs[msl_idx];
>>> | ^~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Snippet of build after fix
>>> ..lib/librte_eal/linux/eal/eal_memory.c: In function ‘remap_segment’:
>>> ..lib/librte_eal/linux/eal/eal_memory.c:685:9: warning: taking address
>>> of packed member of ‘struct rte_mem_config’ may result in an unaligned
>>> pointer value [-Waddress-of-packed-member]
>>> 685 | msl = &mcfg->memsegs[msl_idx];
>>>
>>
>> Fixing these would require an ABI break, because these are exposed
>> externally. Should we submit a deprecation notice for EAL?
>
>
> Ideally mem config and related structures would not be exposed in the
> API. Like lcore_config and eal_config it should be eal_private
>
In a perfect world, that would've been the case. However, these are in
shared memory structures that are used for multiprocess synchronization.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
We have an incorrect variable name in this log.
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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index d5fad04..9ada81e 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -98,7 +98,7 @@ check_for_rule_violations()
then
# Just inform the user of this occurrence, but
# don't flag it as an error
- echo -n "INFO: symbol $syname is added but "
+ echo -n "INFO: symbol $symname is added but "
echo -n "patch has insuficient context "
echo -n "to determine the section name "
echo -n "please ensure the version is "
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 15:03 0% ` Neil Horman
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Even if rare, the check script should handle removing a section.
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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 8da7650..d5fad04 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -32,6 +32,7 @@ build_map_changes()
# symbol rule below
/^.*{/ {
gsub("+", "");
+ gsub("-", "");
if (in_map == 1) {
sec=$(NF-1); in_sec=1;
}
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-09 21:40 0% ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
The incriminated commit broke the detection of new symbols skipping the
EXPERIMENTAL step before entering a stable abi section.
sed won't return an error, check a null output instead.
Fixes: 3630757803ab ("devtools: accept experimental symbol promotion")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 9ada81e..116c311 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -111,15 +111,24 @@ check_for_rule_violations()
# A symbol can not enter a non experimental
# section directly
- if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
+ if [ -z "$oldsecname" ]
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
- continue
+ if [ "$secname" = 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname has "
+ echo -n "been added to the "
+ echo -n "EXPERIMENTAL section of the "
+ echo "version map"
+ continue
+ else
+ 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
fi
# This symbol is moving inside a section, nothing to do
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
We have an incorrect variable name in this log.
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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index d5fad04..9ada81e 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -98,7 +98,7 @@ check_for_rule_violations()
then
# Just inform the user of this occurrence, but
# don't flag it as an error
- echo -n "INFO: symbol $syname is added but "
+ echo -n "INFO: symbol $symname is added but "
echo -n "patch has insuficient context "
echo -n "to determine the section name "
echo -n "please ensure the version is "
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-03 15:03 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
Even if rare, the check script should handle removing a section.
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 | 1 +
1 file changed, 1 insertion(+)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 8da7650..d5fad04 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -32,6 +32,7 @@ build_map_changes()
# symbol rule below
/^.*{/ {
gsub("+", "");
+ gsub("-", "");
if (in_map == 1) {
sec=$(NF-1); in_sec=1;
}
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
@ 2019-05-03 14:34 3% ` David Marchand
2019-05-09 21:40 0% ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 14:34 UTC (permalink / raw)
To: dev; +Cc: thomas, nhorman, stable
The incriminated commit broke the detection of new symbols skipping the
EXPERIMENTAL step before entering a stable abi section.
sed won't return an error, check a null output instead.
Fixes: 3630757803ab ("devtools: accept experimental symbol promotion")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-symbol-change.sh | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 9ada81e..116c311 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -111,15 +111,24 @@ check_for_rule_violations()
# A symbol can not enter a non experimental
# section directly
- if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
+ if [ -z "$oldsecname" ]
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
- continue
+ if [ "$secname" = 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname has "
+ echo -n "been added to the "
+ echo -n "EXPERIMENTAL section of the "
+ echo "version map"
+ continue
+ else
+ 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
fi
# This symbol is moving inside a section, nothing to do
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
2019-05-03 14:34 3% ` David Marchand
@ 2019-05-03 15:03 0% ` Neil Horman
2019-05-03 15:03 0% ` Neil Horman
2019-05-03 17:16 0% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Neil Horman @ 2019-05-03 15:03 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> Even if rare, the check script should handle removing a section.
>
> 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 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 8da7650..d5fad04 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -32,6 +32,7 @@ build_map_changes()
> # symbol rule below
> /^.*{/ {
> gsub("+", "");
> + gsub("-", "");
> if (in_map == 1) {
> sec=$(NF-1); in_sec=1;
> }
> --
> 1.8.3.1
>
>
Don't you also need to add some logic in the symbol detection match rule to
print an appropriate indicator that a symbol is being removed? With just this
change, you will note that you are parsing a section, but you will never trigger
a symbol match
Neil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 15:03 0% ` Neil Horman
@ 2019-05-03 15:03 0% ` Neil Horman
2019-05-03 17:16 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Neil Horman @ 2019-05-03 15:03 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, stable
On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> Even if rare, the check script should handle removing a section.
>
> 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 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 8da7650..d5fad04 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -32,6 +32,7 @@ build_map_changes()
> # symbol rule below
> /^.*{/ {
> gsub("+", "");
> + gsub("-", "");
> if (in_map == 1) {
> sec=$(NF-1); in_sec=1;
> }
> --
> 1.8.3.1
>
>
Don't you also need to add some logic in the symbol detection match rule to
print an appropriate indicator that a symbol is being removed? With just this
change, you will note that you are parsing a section, but you will never trigger
a symbol match
Neil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
@ 2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:25 0% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-05-03 16:01 UTC (permalink / raw)
To: Thomas Monjalon, Reshma Pattan
Cc: dev, David Marchand, bruce.richardson, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Thursday, May 2, 2019 9:27 PM
> To: Reshma Pattan <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
>
> 02/05/2019 17:00, David Marchand:
> > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > <reshma.pattan@intel.com>
> > wrote:
> >
> > > gcc 9 on Fedora 30 gives an error
> > > "taking address of packed member may result in an unaligned pointer
> > > value" warnings.
> > >
> > > For clang builds this warning is already disabled, so disable
> > > "-Waddress-of-packed-member" for gcc builds also.
> > >
> > > Snippet of build error:
> > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > address of packed member of ‘struct rte_mem_config’ may result in an
> > > unaligned pointer value [-Werror=address-of-packed-member]
> > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > >
> > >
> > Tested on rhel-7 and fedora-30.
> > Tested-by: David Marchand <david.marchand@redhat.com>
>
> Applied, thanks
Its been found that one of the armv7 toolchain treats
-Wno-address-of-packed-member as unrecognized command line option,
Hence armv7 build fails on dpdk.org master now. Not sure it is specific to armv7 or compiler?
Armv7 is not maintained and I don’t think, it has any use case for DPDK.
If everyone agrees IMO it is better remove the arm 32bit support.
arm-buildroot-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
bin/arm-buildroot-linux-gnueabihf-gcc.br_real
COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
Target: arm-buildroot-linux-gnueabihf
Configured with: ./configure
--prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
--sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
--enable-static --target=arm-buildroot-linux-gnueabihf
--with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
arm-buildroot-linux-gnueabihf/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
--with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
--enable-tls --disable-libmudflap --enable-threads --without-isl
--without-cloog --disable-decimal-float --with-abi=aa
pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
--with-mode=arm --enable-languages=c,c++
--with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
error log:
dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
cc1: error: unrecognized command line option
‘-Wno-address-of-packed-member’ [-Werror]
cc1: all warnings being treated as errors
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
@ 2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:25 0% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-05-03 16:01 UTC (permalink / raw)
To: Thomas Monjalon, Reshma Pattan
Cc: dev, David Marchand, bruce.richardson, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Thursday, May 2, 2019 9:27 PM
> To: Reshma Pattan <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
>
> 02/05/2019 17:00, David Marchand:
> > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > <reshma.pattan@intel.com>
> > wrote:
> >
> > > gcc 9 on Fedora 30 gives an error
> > > "taking address of packed member may result in an unaligned pointer
> > > value" warnings.
> > >
> > > For clang builds this warning is already disabled, so disable
> > > "-Waddress-of-packed-member" for gcc builds also.
> > >
> > > Snippet of build error:
> > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > address of packed member of ‘struct rte_mem_config’ may result in an
> > > unaligned pointer value [-Werror=address-of-packed-member]
> > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > >
> > >
> > Tested on rhel-7 and fedora-30.
> > Tested-by: David Marchand <david.marchand@redhat.com>
>
> Applied, thanks
Its been found that one of the armv7 toolchain treats
-Wno-address-of-packed-member as unrecognized command line option,
Hence armv7 build fails on dpdk.org master now. Not sure it is specific to armv7 or compiler?
Armv7 is not maintained and I don’t think, it has any use case for DPDK.
If everyone agrees IMO it is better remove the arm 32bit support.
arm-buildroot-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
bin/arm-buildroot-linux-gnueabihf-gcc.br_real
COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
Target: arm-buildroot-linux-gnueabihf
Configured with: ./configure
--prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
--sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
--enable-static --target=arm-buildroot-linux-gnueabihf
--with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
arm-buildroot-linux-gnueabihf/sysroot
--disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
--with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
--with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
--enable-tls --disable-libmudflap --enable-threads --without-isl
--without-cloog --disable-decimal-float --with-abi=aa
pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
--with-mode=arm --enable-languages=c,c++
--with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
error log:
dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
cc1: error: unrecognized command line option
‘-Wno-address-of-packed-member’ [-Werror]
cc1: all warnings being treated as errors
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
@ 2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:25 0% ` Bruce Richardson
` (2 more replies)
1 sibling, 3 replies; 200+ results
From: Bruce Richardson @ 2019-05-03 16:25 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Thomas Monjalon, Reshma Pattan, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > Sent: Thursday, May 2, 2019 9:27 PM
> > To: Reshma Pattan <reshma.pattan@intel.com>
> > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
> >
> > 02/05/2019 17:00, David Marchand:
> > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > <reshma.pattan@intel.com>
> > > wrote:
> > >
> > > > gcc 9 on Fedora 30 gives an error
> > > > "taking address of packed member may result in an unaligned pointer
> > > > value" warnings.
> > > >
> > > > For clang builds this warning is already disabled, so disable
> > > > "-Waddress-of-packed-member" for gcc builds also.
> > > >
> > > > Snippet of build error:
> > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > address of packed member of ‘struct rte_mem_config’ may result in an
> > > > unaligned pointer value [-Werror=address-of-packed-member]
> > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > >
> > > >
> > > Tested on rhel-7 and fedora-30.
> > > Tested-by: David Marchand <david.marchand@redhat.com>
> >
> > Applied, thanks
>
> Its been found that one of the armv7 toolchain treats
> -Wno-address-of-packed-member as unrecognized command line option,
> Hence armv7 build fails on dpdk.org master now. Not sure it is specific to armv7 or compiler?
>
> Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> If everyone agrees IMO it is better remove the arm 32bit support.
>
> arm-buildroot-linux-gnueabihf-gcc -v
> Using built-in specs.
> COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> Target: arm-buildroot-linux-gnueabihf
> Configured with: ./configure
> --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> --enable-static --target=arm-buildroot-linux-gnueabihf
> --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> arm-buildroot-linux-gnueabihf/sysroot
> --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
> --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> --enable-tls --disable-libmudflap --enable-threads --without-isl
> --without-cloog --disable-decimal-float --with-abi=aa
> pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> --with-mode=arm --enable-languages=c,c++
> --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> Thread model: posix
> gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
>
> error log:
>
> dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> cc1: error: unrecognized command line option
> ‘-Wno-address-of-packed-member’ [-Werror]
> cc1: all warnings being treated as errors
>
Are you sure there is not another error as well? GCC silently ignores flags
like this one normally, but does report them as unrecognised if-and-only-if
another error or warning is given too.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:25 0% ` Bruce Richardson
@ 2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:28 0% ` Richardson, Bruce
2019-05-03 17:24 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-05-03 16:25 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: Thomas Monjalon, Reshma Pattan, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > Sent: Thursday, May 2, 2019 9:27 PM
> > To: Reshma Pattan <reshma.pattan@intel.com>
> > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
> >
> > 02/05/2019 17:00, David Marchand:
> > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > <reshma.pattan@intel.com>
> > > wrote:
> > >
> > > > gcc 9 on Fedora 30 gives an error
> > > > "taking address of packed member may result in an unaligned pointer
> > > > value" warnings.
> > > >
> > > > For clang builds this warning is already disabled, so disable
> > > > "-Waddress-of-packed-member" for gcc builds also.
> > > >
> > > > Snippet of build error:
> > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > address of packed member of ‘struct rte_mem_config’ may result in an
> > > > unaligned pointer value [-Werror=address-of-packed-member]
> > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > >
> > > >
> > > Tested on rhel-7 and fedora-30.
> > > Tested-by: David Marchand <david.marchand@redhat.com>
> >
> > Applied, thanks
>
> Its been found that one of the armv7 toolchain treats
> -Wno-address-of-packed-member as unrecognized command line option,
> Hence armv7 build fails on dpdk.org master now. Not sure it is specific to armv7 or compiler?
>
> Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> If everyone agrees IMO it is better remove the arm 32bit support.
>
> arm-buildroot-linux-gnueabihf-gcc -v
> Using built-in specs.
> COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> Target: arm-buildroot-linux-gnueabihf
> Configured with: ./configure
> --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> --enable-static --target=arm-buildroot-linux-gnueabihf
> --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> arm-buildroot-linux-gnueabihf/sysroot
> --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
> --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> --enable-tls --disable-libmudflap --enable-threads --without-isl
> --without-cloog --disable-decimal-float --with-abi=aa
> pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> --with-mode=arm --enable-languages=c,c++
> --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> Thread model: posix
> gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
>
> error log:
>
> dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> cc1: error: unrecognized command line option
> ‘-Wno-address-of-packed-member’ [-Werror]
> cc1: all warnings being treated as errors
>
Are you sure there is not another error as well? GCC silently ignores flags
like this one normally, but does report them as unrecognised if-and-only-if
another error or warning is given too.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:25 0% ` Bruce Richardson
@ 2019-05-03 16:28 0% ` Richardson, Bruce
2019-05-03 16:28 0% ` Richardson, Bruce
2019-05-03 17:24 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2 siblings, 1 reply; 200+ results
From: Richardson, Bruce @ 2019-05-03 16:28 UTC (permalink / raw)
To: Richardson, Bruce, Jerin Jacob Kollanukkaran
Cc: Thomas Monjalon, Pattan, Reshma, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, May 3, 2019 5:25 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora
> 30
>
> On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Thursday, May 2, 2019 9:27 PM
> > > To: Reshma Pattan <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on
> > > Fedora 30
> > >
> > > 02/05/2019 17:00, David Marchand:
> > > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > > <reshma.pattan@intel.com>
> > > > wrote:
> > > >
> > > > > gcc 9 on Fedora 30 gives an error "taking address of packed
> > > > > member may result in an unaligned pointer value" warnings.
> > > > >
> > > > > For clang builds this warning is already disabled, so disable
> > > > > "-Waddress-of-packed-member" for gcc builds also.
> > > > >
> > > > > Snippet of build error:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function
> ‘alloc_seg_walk’:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > > address of packed member of ‘struct rte_mem_config’ may result
> > > > > in an unaligned pointer value [-Werror=address-of-packed-member]
> > > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > >
> > > > >
> > > > Tested on rhel-7 and fedora-30.
> > > > Tested-by: David Marchand <david.marchand@redhat.com>
> > >
> > > Applied, thanks
> >
> > Its been found that one of the armv7 toolchain treats
> > -Wno-address-of-packed-member as unrecognized command line option,
> > Hence armv7 build fails on dpdk.org master now. Not sure it is specific
> to armv7 or compiler?
> >
> > Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> > If everyone agrees IMO it is better remove the arm 32bit support.
> >
> > arm-buildroot-linux-gnueabihf-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> > COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> > Target: arm-buildroot-linux-gnueabihf
> > Configured with: ./configure
> > --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> > --enable-static --target=arm-buildroot-linux-gnueabihf
> > --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/sysroot
> > --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-
> multilib
> > --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> > --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> > --enable-tls --disable-libmudflap --enable-threads --without-isl
> > --without-cloog --disable-decimal-float --with-abi=aa
> > pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-
> float=hard
> > --with-mode=arm --enable-languages=c,c++
> > --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> > Thread model: posix
> > gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
> >
> > error log:
> >
> > dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> > cc1: error: unrecognized command line option
> > ‘-Wno-address-of-packed-member’ [-Werror]
> > cc1: all warnings being treated as errors
> >
>
> Are you sure there is not another error as well? GCC silently ignores
> flags like this one normally, but does report them as unrecognised if-and-
> only-if another error or warning is given too.
>
> /Bruce
For completeness, ref: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
"When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC emits a diagnostic stating that the option is not recognized. However, if the -Wno- form is used, the behavior is slightly different: no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced. This allows the use of new -Wno- options with old compilers, but if something goes wrong, the compiler warns that an unrecognized option is present."
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:28 0% ` Richardson, Bruce
@ 2019-05-03 16:28 0% ` Richardson, Bruce
0 siblings, 0 replies; 200+ results
From: Richardson, Bruce @ 2019-05-03 16:28 UTC (permalink / raw)
To: Richardson, Bruce, Jerin Jacob Kollanukkaran
Cc: Thomas Monjalon, Pattan, Reshma, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, May 3, 2019 5:25 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora
> 30
>
> On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Thursday, May 2, 2019 9:27 PM
> > > To: Reshma Pattan <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on
> > > Fedora 30
> > >
> > > 02/05/2019 17:00, David Marchand:
> > > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > > <reshma.pattan@intel.com>
> > > > wrote:
> > > >
> > > > > gcc 9 on Fedora 30 gives an error "taking address of packed
> > > > > member may result in an unaligned pointer value" warnings.
> > > > >
> > > > > For clang builds this warning is already disabled, so disable
> > > > > "-Waddress-of-packed-member" for gcc builds also.
> > > > >
> > > > > Snippet of build error:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function
> ‘alloc_seg_walk’:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > > address of packed member of ‘struct rte_mem_config’ may result
> > > > > in an unaligned pointer value [-Werror=address-of-packed-member]
> > > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > >
> > > > >
> > > > Tested on rhel-7 and fedora-30.
> > > > Tested-by: David Marchand <david.marchand@redhat.com>
> > >
> > > Applied, thanks
> >
> > Its been found that one of the armv7 toolchain treats
> > -Wno-address-of-packed-member as unrecognized command line option,
> > Hence armv7 build fails on dpdk.org master now. Not sure it is specific
> to armv7 or compiler?
> >
> > Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> > If everyone agrees IMO it is better remove the arm 32bit support.
> >
> > arm-buildroot-linux-gnueabihf-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> > COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> > Target: arm-buildroot-linux-gnueabihf
> > Configured with: ./configure
> > --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> > --enable-static --target=arm-buildroot-linux-gnueabihf
> > --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/sysroot
> > --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-
> multilib
> > --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> > --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> > --enable-tls --disable-libmudflap --enable-threads --without-isl
> > --without-cloog --disable-decimal-float --with-abi=aa
> > pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-
> float=hard
> > --with-mode=arm --enable-languages=c,c++
> > --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> > Thread model: posix
> > gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
> >
> > error log:
> >
> > dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> > cc1: error: unrecognized command line option
> > ‘-Wno-address-of-packed-member’ [-Werror]
> > cc1: all warnings being treated as errors
> >
>
> Are you sure there is not another error as well? GCC silently ignores
> flags like this one normally, but does report them as unrecognised if-and-
> only-if another error or warning is given too.
>
> /Bruce
For completeness, ref: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
"When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC emits a diagnostic stating that the option is not recognized. However, if the -Wno- form is used, the behavior is slightly different: no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced. This allows the use of new -Wno- options with old compilers, but if something goes wrong, the compiler warns that an unrecognized option is present."
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 15:03 0% ` Neil Horman
2019-05-03 15:03 0% ` Neil Horman
@ 2019-05-03 17:16 0% ` David Marchand
2019-05-03 17:16 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2019-05-03 17:16 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Thomas Monjalon, dpdk stable
On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> > Even if rare, the check script should handle removing a section.
> >
> > 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 | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/devtools/check-symbol-change.sh
> b/devtools/check-symbol-change.sh
> > index 8da7650..d5fad04 100755
> > --- a/devtools/check-symbol-change.sh
> > +++ b/devtools/check-symbol-change.sh
> > @@ -32,6 +32,7 @@ build_map_changes()
> > # symbol rule below
> > /^.*{/ {
> > gsub("+", "");
> > + gsub("-", "");
> > if (in_map == 1) {
> > sec=$(NF-1); in_sec=1;
> > }
> > --
> > 1.8.3.1
> >
> >
> Don't you also need to add some logic in the symbol detection match rule to
> print an appropriate indicator that a symbol is being removed? With just
> this
> change, you will note that you are parsing a section, but you will never
> trigger
> a symbol match
>
I do remember seeing a warning about the "-EXPERIMENTAL" section.
And this is why I added this.
But since then I reorganised my series and eliminated some parts... so you
are most likely right.
I will double check and repost.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 17:16 0% ` David Marchand
@ 2019-05-03 17:16 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-05-03 17:16 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Thomas Monjalon, dpdk stable
On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> > Even if rare, the check script should handle removing a section.
> >
> > 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 | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/devtools/check-symbol-change.sh
> b/devtools/check-symbol-change.sh
> > index 8da7650..d5fad04 100755
> > --- a/devtools/check-symbol-change.sh
> > +++ b/devtools/check-symbol-change.sh
> > @@ -32,6 +32,7 @@ build_map_changes()
> > # symbol rule below
> > /^.*{/ {
> > gsub("+", "");
> > + gsub("-", "");
> > if (in_map == 1) {
> > sec=$(NF-1); in_sec=1;
> > }
> > --
> > 1.8.3.1
> >
> >
> Don't you also need to add some logic in the symbol detection match rule to
> print an appropriate indicator that a symbol is being removed? With just
> this
> change, you will note that you are parsing a section, but you will never
> trigger
> a symbol match
>
I do remember seeing a warning about the "-EXPERIMENTAL" section.
And this is why I added this.
But since then I reorganised my series and eliminated some parts... so you
are most likely right.
I will double check and repost.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:28 0% ` Richardson, Bruce
@ 2019-05-03 17:24 0% ` Jerin Jacob Kollanukkaran
2019-05-03 17:24 0% ` Jerin Jacob Kollanukkaran
2 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-05-03 17:24 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, Reshma Pattan, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Friday, May 3, 2019 9:55 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Reshma Pattan
> <reshma.pattan@intel.com>; dev@dpdk.org; David Marchand
> <david.marchand@redhat.com>; viktorin@rehivetech.com; Gavin Hu (Arm
> Technology China) <Gavin.Hu@arm.com>
> Subject: [EXT] Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora
> On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Thursday, May 2, 2019 9:27 PM
> > > To: Reshma Pattan <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on
> > > Fedora 30
> > >
> > > 02/05/2019 17:00, David Marchand:
> > > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > > <reshma.pattan@intel.com>
> > > > wrote:
> > > >
> > > > > gcc 9 on Fedora 30 gives an error "taking address of packed
> > > > > member may result in an unaligned pointer value" warnings.
> > > > >
> > > > > For clang builds this warning is already disabled, so disable
> > > > > "-Waddress-of-packed-member" for gcc builds also.
> > > > >
> > > > > Snippet of build error:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > > address of packed member of ‘struct rte_mem_config’ may result
> > > > > in an unaligned pointer value [-Werror=address-of-packed-member]
> > > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > >
> > > > >
> > > > Tested on rhel-7 and fedora-30.
> > > > Tested-by: David Marchand <david.marchand@redhat.com>
> > >
> > > Applied, thanks
> >
> > Its been found that one of the armv7 toolchain treats
> > -Wno-address-of-packed-member as unrecognized command line option,
> > Hence armv7 build fails on dpdk.org master now. Not sure it is specific to
> armv7 or compiler?
> >
> > Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> > If everyone agrees IMO it is better remove the arm 32bit support.
> >
> > arm-buildroot-linux-gnueabihf-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> > COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> > Target: arm-buildroot-linux-gnueabihf
> > Configured with: ./configure
> > --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> > --enable-static --target=arm-buildroot-linux-gnueabihf
> > --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/sysroot
> > --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
> > --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> > --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> > --enable-tls --disable-libmudflap --enable-threads --without-isl
> > --without-cloog --disable-decimal-float --with-abi=aa
> > pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> > --with-mode=arm --enable-languages=c,c++
> > --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> > Thread model: posix
> > gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
> >
> > error log:
> >
> > dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> > cc1: error: unrecognized command line option
> > ‘-Wno-address-of-packed-member’ [-Werror]
> > cc1: all warnings being treated as errors
> >
>
> Are you sure there is not another error as well? GCC silently ignores flags like
> this one normally, but does report them as unrecognised if-and-only-if another
> error or warning is given too.
That’s explains reason for error for armv7(the file has other warnings).
There are plenty of warning for armv7 port. That is the one reason why, I think, we need to remove
Armv7 port if there is no end user for it. It just a pain to maintain it.
arm-buildroot-linux-gnueabihf-gcc -Wp,-MD,./.eal_vfio.o.d.tmp -marm -munaligned-access -pthread -I/home/jerin/dpdk.org/lib/librte_eal/linux/eal/include -march=armv7-a -mtune=cortex-a9 -mfpu
=neon -DRTE_MACHINE_CPUFLAG_NEON -I/home/jerin/dpdk.org/build/include -include /home/jerin/dpdk.org/build/include/rte_config.h -D_GNU_SOURCE -DALLOW_EXPERIMENTAL_API -I/home/jerin/dpdk.org/l
ib/librte_eal/linux/eal/include -I/home/jerin/dpdk.org/lib/librte_eal/common -I/home/jerin/dpdk.org/lib/librte_eal/common/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-d
eclarations -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Wdeprecated -Werror -Wno-error=cast
-align -Wimplicit-fallthrough=2 -Wno-format-truncation -Wno-address-of-packed-member -O3 -o eal_vfio.o -c /home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_open_group_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:268:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:315:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_sync_default_container’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:558:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:583:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_get_default_container_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1027:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1048:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘rte_vfio_get_container_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1133:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1179:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’ [-Werror]
cc1: all warnings being treated as errors
make[5]: *** [/home/jerin/dpdk.org/mk/internal/rte.compile-pre.mk:116: eal_vfio.o] Error 1
make[4]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: eal] Error 2
make[3]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: linux] Error 2
make[2]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: librte_eal] Error 2
make[1]: *** [/home/jerin/dpdk.org/mk/rte.sdkbuild.mk:48: lib] Error 2
make: *** [/home/jerin/dpdk.org/mk/rte.sdkroot.mk:99: all] Error 2
>
> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH] mk: disable warning with gcc 9 on Fedora 30
2019-05-03 17:24 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-05-03 17:24 0% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-05-03 17:24 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, Reshma Pattan, dev, David Marchand, viktorin,
Gavin Hu (Arm Technology China)
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Friday, May 3, 2019 9:55 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Reshma Pattan
> <reshma.pattan@intel.com>; dev@dpdk.org; David Marchand
> <david.marchand@redhat.com>; viktorin@rehivetech.com; Gavin Hu (Arm
> Technology China) <Gavin.Hu@arm.com>
> Subject: [EXT] Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora
> On Fri, May 03, 2019 at 04:01:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Thursday, May 2, 2019 9:27 PM
> > > To: Reshma Pattan <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>
> > > Subject: Re: [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on
> > > Fedora 30
> > >
> > > 02/05/2019 17:00, David Marchand:
> > > > On Thu, May 2, 2019 at 11:33 AM Reshma Pattan
> > > > <reshma.pattan@intel.com>
> > > > wrote:
> > > >
> > > > > gcc 9 on Fedora 30 gives an error "taking address of packed
> > > > > member may result in an unaligned pointer value" warnings.
> > > > >
> > > > > For clang builds this warning is already disabled, so disable
> > > > > "-Waddress-of-packed-member" for gcc builds also.
> > > > >
> > > > > Snippet of build error:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c: In function ‘alloc_seg_walk’:
> > > > > ...lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error: taking
> > > > > address of packed member of ‘struct rte_mem_config’ may result
> > > > > in an unaligned pointer value [-Werror=address-of-packed-member]
> > > > > 768 | cur_msl = &mcfg->memsegs[msl_idx];
> > > > > | ^~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > >
> > > > >
> > > > Tested on rhel-7 and fedora-30.
> > > > Tested-by: David Marchand <david.marchand@redhat.com>
> > >
> > > Applied, thanks
> >
> > Its been found that one of the armv7 toolchain treats
> > -Wno-address-of-packed-member as unrecognized command line option,
> > Hence armv7 build fails on dpdk.org master now. Not sure it is specific to
> armv7 or compiler?
> >
> > Armv7 is not maintained and I don’t think, it has any use case for DPDK.
> > If everyone agrees IMO it is better remove the arm 32bit support.
> >
> > arm-buildroot-linux-gnueabihf-gcc -v
> > Using built-in specs.
> > COLLECT_GCC=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > bin/arm-buildroot-linux-gnueabihf-gcc.br_real
> > COLLECT_LTO_WRAPPER=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > libexec/gcc/arm-buildroot-linux-gnueabihf/7.3.0/lto-wrapper
> > Target: arm-buildroot-linux-gnueabihf
> > Configured with: ./configure
> > --prefix=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --sysconfdir=/opt/armv7-eabihf--glibc--stable-2018.11-1/etc
> > --enable-static --target=arm-buildroot-linux-gnueabihf
> > --with-sysroot=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/sysroot
> > --disable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
> > --with-gmp=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpc=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-mpfr=/opt/armv7-eabihf--glibc--stable-2018.11-1
> > --with-pkgversion='Buildroot 2018.08.1-00003-g576b333'
> > --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath
> > --enable-tls --disable-libmudflap --enable-threads --without-isl
> > --without-cloog --disable-decimal-float --with-abi=aa
> > pcs-linux --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
> > --with-mode=arm --enable-languages=c,c++
> > --with-build-time-tools=/opt/armv7-eabihf--glibc--stable-2018.11-1/
> > arm-buildroot-linux-gnueabihf/bin --enable-shared --disable-libgomp
> > Thread model: posix
> > gcc version 7.3.0 (Buildroot 2018.08.1-00003-g576b333)
> >
> > error log:
> >
> > dpdk.org/lib/librte_eal/linux/eal/eal_vfio_mp_sync.c: At top level:
> > cc1: error: unrecognized command line option
> > ‘-Wno-address-of-packed-member’ [-Werror]
> > cc1: all warnings being treated as errors
> >
>
> Are you sure there is not another error as well? GCC silently ignores flags like
> this one normally, but does report them as unrecognised if-and-only-if another
> error or warning is given too.
That’s explains reason for error for armv7(the file has other warnings).
There are plenty of warning for armv7 port. That is the one reason why, I think, we need to remove
Armv7 port if there is no end user for it. It just a pain to maintain it.
arm-buildroot-linux-gnueabihf-gcc -Wp,-MD,./.eal_vfio.o.d.tmp -marm -munaligned-access -pthread -I/home/jerin/dpdk.org/lib/librte_eal/linux/eal/include -march=armv7-a -mtune=cortex-a9 -mfpu
=neon -DRTE_MACHINE_CPUFLAG_NEON -I/home/jerin/dpdk.org/build/include -include /home/jerin/dpdk.org/build/include/rte_config.h -D_GNU_SOURCE -DALLOW_EXPERIMENTAL_API -I/home/jerin/dpdk.org/l
ib/librte_eal/linux/eal/include -I/home/jerin/dpdk.org/lib/librte_eal/common -I/home/jerin/dpdk.org/lib/librte_eal/common/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-d
eclarations -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Wdeprecated -Werror -Wno-error=cast
-align -Wimplicit-fallthrough=2 -Wno-format-truncation -Wno-address-of-packed-member -O3 -o eal_vfio.o -c /home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_open_group_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:268:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:315:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_sync_default_container’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:558:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:583:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘vfio_get_default_container_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1027:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1048:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: In function ‘rte_vfio_get_container_fd’:
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1133:28: warning: cast increases required alignment of target type [-Wcast-align]
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c:1179:7: warning: cast increases required alignment of target type [-Wcast-align]
p = (struct vfio_mp_param *)mp_rep->param;
^
/home/jerin/dpdk.org/lib/librte_eal/linux/eal/eal_vfio.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’ [-Werror]
cc1: all warnings being treated as errors
make[5]: *** [/home/jerin/dpdk.org/mk/internal/rte.compile-pre.mk:116: eal_vfio.o] Error 1
make[4]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: eal] Error 2
make[3]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: linux] Error 2
make[2]: *** [/home/jerin/dpdk.org/mk/rte.subdir.mk:37: librte_eal] Error 2
make[1]: *** [/home/jerin/dpdk.org/mk/rte.sdkbuild.mk:48: lib] Error 2
make: *** [/home/jerin/dpdk.org/mk/rte.sdkroot.mk:99: all] Error 2
>
> /Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
@ 2019-05-03 17:25 8% ` Stephen Hemminger
2019-05-03 17:25 8% ` Stephen Hemminger
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Stephen Hemminger @ 2019-05-03 17:25 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
Changes for v3 (based on David's feedback):
- rte_lcore_index should not be experimental
- eal map should chain from 18.11
- more fixes in bond example
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 | 13 +++---
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 139 insertions(+), 55 deletions(-)
--
2.20.1
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI
2019-05-03 17:25 8% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI Stephen Hemminger
@ 2019-05-03 17:25 8% ` Stephen Hemminger
2019-05-03 17:25 9% ` [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-05-06 7:20 4% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI David Marchand
2 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-03 17:25 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
Changes for v3 (based on David's feedback):
- rte_lcore_index should not be experimental
- eal map should chain from 18.11
- more fixes in bond example
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 | 13 +++---
lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++
lib/librte_eal/common/include/rte_lcore.h | 57 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
11 files changed, 139 insertions(+), 55 deletions(-)
--
2.20.1
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config
2019-05-03 17:25 8% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI Stephen Hemminger
2019-05-03 17:25 8% ` Stephen Hemminger
@ 2019-05-03 17:25 9% ` Stephen Hemminger
2019-05-03 17:25 9% ` Stephen Hemminger
2019-05-06 7:20 4% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI David Marchand
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-05-03 17:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, David Marchand
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 | 49 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 91 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 468e325395c7..35c0c9081958 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -275,6 +275,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 8c2744fabcbf..ae59c98ca43a 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 705594acbb5e..d0006a077fae 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,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 245493461c36..b4aec1667122 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -287,6 +287,16 @@ DPDK_19.05 {
} DPDK_18.11;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.11;
+
EXPERIMENTAL {
global:
@@ -337,6 +347,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.20.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config
2019-05-03 17:25 9% ` [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-05-03 17:25 9% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-03 17:25 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, David Marchand
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 | 49 ++++++++++++++++-------
lib/librte_eal/rte_eal_version.map | 11 +++++
4 files changed, 91 insertions(+), 14 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 468e325395c7..35c0c9081958 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -275,6 +275,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 8c2744fabcbf..ae59c98ca43a 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 705594acbb5e..d0006a077fae 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,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 245493461c36..b4aec1667122 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -287,6 +287,16 @@ DPDK_19.05 {
} DPDK_18.11;
+DPDK_19.05 {
+ global:
+
+ rte_lcore_cpuset;
+ rte_lcore_index;
+ rte_lcore_to_cpu_id;
+ rte_lcore_to_socket_id;
+
+} DPDK_18.11;
+
EXPERIMENTAL {
global:
@@ -337,6 +347,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.20.1
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI
2019-05-03 17:25 8% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI Stephen Hemminger
2019-05-03 17:25 8% ` Stephen Hemminger
2019-05-03 17:25 9% ` [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
@ 2019-05-06 7:20 4% ` David Marchand
2019-05-06 7:20 4% ` David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-06 7:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Fri, May 3, 2019 at 7:25 PM Stephen Hemminger <stephen@networkplumber.org>
wrote:
> 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
>
> Changes for v3 (based on David's feedback):
> - rte_lcore_index should not be experimental
> - eal map should chain from 18.11
> - more fixes in bond example
>
> 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 | 13 +++---
> lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++
> lib/librte_eal/common/include/rte_lcore.h | 57 ++++++++++++++++-------
> lib/librte_eal/rte_eal_version.map | 11 +++++
> 11 files changed, 139 insertions(+), 55 deletions(-)
>
> --
> 2.20.1
>
>
LGTM.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI
2019-05-06 7:20 4% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI David Marchand
@ 2019-05-06 7:20 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-06 7:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Fri, May 3, 2019 at 7:25 PM Stephen Hemminger <stephen@networkplumber.org>
wrote:
> 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
>
> Changes for v3 (based on David's feedback):
> - rte_lcore_index should not be experimental
> - eal map should chain from 18.11
> - more fixes in bond example
>
> 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 | 13 +++---
> lib/librte_eal/common/eal_common_lcore.c | 39 ++++++++++++++++
> lib/librte_eal/common/include/rte_lcore.h | 57 ++++++++++++++++-------
> lib/librte_eal/rte_eal_version.map | 11 +++++
> 11 files changed, 139 insertions(+), 55 deletions(-)
>
> --
> 2.20.1
>
>
LGTM.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-03 17:16 0% ` David Marchand
2019-05-03 17:16 0% ` David Marchand
@ 2019-05-06 12:56 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
2019-05-06 15:43 0% ` Neil Horman
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2019-05-06 12:56 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Thomas Monjalon, dpdk stable
On Fri, May 3, 2019 at 7:16 PM David Marchand <david.marchand@redhat.com>
wrote:
> On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
>> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
>> > Even if rare, the check script should handle removing a section.
>> >
>> > 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 | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/devtools/check-symbol-change.sh
>> b/devtools/check-symbol-change.sh
>> > index 8da7650..d5fad04 100755
>> > --- a/devtools/check-symbol-change.sh
>> > +++ b/devtools/check-symbol-change.sh
>> > @@ -32,6 +32,7 @@ build_map_changes()
>> > # symbol rule below
>> > /^.*{/ {
>> > gsub("+", "");
>> > + gsub("-", "");
>> > if (in_map == 1) {
>> > sec=$(NF-1); in_sec=1;
>> > }
>> > --
>> > 1.8.3.1
>> >
>> >
>> Don't you also need to add some logic in the symbol detection match rule
>> to
>> print an appropriate indicator that a symbol is being removed? With just
>> this
>> change, you will note that you are parsing a section, but you will never
>> trigger
>> a symbol match
>>
>
> I do remember seeing a warning about the "-EXPERIMENTAL" section.
> And this is why I added this.
> But since then I reorganised my series and eliminated some parts... so you
> are most likely right.
> I will double check and repost.
>
>
Yes, you are right, I moved this out of another patch that I ended up not
sending.
But it makes no sense by itself.
I will drop this in v2.
Any comments on the other patches ?
Thanks Neil.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-06 12:56 0% ` David Marchand
@ 2019-05-06 12:56 0% ` David Marchand
2019-05-06 15:43 0% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-05-06 12:56 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Thomas Monjalon, dpdk stable
On Fri, May 3, 2019 at 7:16 PM David Marchand <david.marchand@redhat.com>
wrote:
> On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
>> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
>> > Even if rare, the check script should handle removing a section.
>> >
>> > 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 | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/devtools/check-symbol-change.sh
>> b/devtools/check-symbol-change.sh
>> > index 8da7650..d5fad04 100755
>> > --- a/devtools/check-symbol-change.sh
>> > +++ b/devtools/check-symbol-change.sh
>> > @@ -32,6 +32,7 @@ build_map_changes()
>> > # symbol rule below
>> > /^.*{/ {
>> > gsub("+", "");
>> > + gsub("-", "");
>> > if (in_map == 1) {
>> > sec=$(NF-1); in_sec=1;
>> > }
>> > --
>> > 1.8.3.1
>> >
>> >
>> Don't you also need to add some logic in the symbol detection match rule
>> to
>> print an appropriate indicator that a symbol is being removed? With just
>> this
>> change, you will note that you are parsing a section, but you will never
>> trigger
>> a symbol match
>>
>
> I do remember seeing a warning about the "-EXPERIMENTAL" section.
> And this is why I added this.
> But since then I reorganised my series and eliminated some parts... so you
> are most likely right.
> I will double check and repost.
>
>
Yes, you are right, I moved this out of another patch that I ended up not
sending.
But it makes no sense by itself.
I will drop this in v2.
Any comments on the other patches ?
Thanks Neil.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-06 12:56 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
@ 2019-05-06 15:43 0% ` Neil Horman
2019-05-06 15:43 0% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Neil Horman @ 2019-05-06 15:43 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, dpdk stable
On Mon, May 06, 2019 at 02:56:51PM +0200, David Marchand wrote:
> On Fri, May 3, 2019 at 7:16 PM David Marchand <david.marchand@redhat.com>
> wrote:
>
> > On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> >> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> >> > Even if rare, the check script should handle removing a section.
> >> >
> >> > 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 | 1 +
> >> > 1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/devtools/check-symbol-change.sh
> >> b/devtools/check-symbol-change.sh
> >> > index 8da7650..d5fad04 100755
> >> > --- a/devtools/check-symbol-change.sh
> >> > +++ b/devtools/check-symbol-change.sh
> >> > @@ -32,6 +32,7 @@ build_map_changes()
> >> > # symbol rule below
> >> > /^.*{/ {
> >> > gsub("+", "");
> >> > + gsub("-", "");
> >> > if (in_map == 1) {
> >> > sec=$(NF-1); in_sec=1;
> >> > }
> >> > --
> >> > 1.8.3.1
> >> >
> >> >
> >> Don't you also need to add some logic in the symbol detection match rule
> >> to
> >> print an appropriate indicator that a symbol is being removed? With just
> >> this
> >> change, you will note that you are parsing a section, but you will never
> >> trigger
> >> a symbol match
> >>
> >
> > I do remember seeing a warning about the "-EXPERIMENTAL" section.
> > And this is why I added this.
> > But since then I reorganised my series and eliminated some parts... so you
> > are most likely right.
> > I will double check and repost.
> >
> >
> Yes, you are right, I moved this out of another patch that I ended up not
> sending.
> But it makes no sense by itself.
> I will drop this in v2.
>
> Any comments on the other patches ?
> Thanks Neil.
>
No, I don't think I do, thanks for checking though!
Neil
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 2/4] devtools: handle section suppression
2019-05-06 15:43 0% ` Neil Horman
@ 2019-05-06 15:43 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-05-06 15:43 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, dpdk stable
On Mon, May 06, 2019 at 02:56:51PM +0200, David Marchand wrote:
> On Fri, May 3, 2019 at 7:16 PM David Marchand <david.marchand@redhat.com>
> wrote:
>
> > On Fri, May 3, 2019 at 5:18 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> >
> >> On Fri, May 03, 2019 at 04:34:18PM +0200, David Marchand wrote:
> >> > Even if rare, the check script should handle removing a section.
> >> >
> >> > 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 | 1 +
> >> > 1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/devtools/check-symbol-change.sh
> >> b/devtools/check-symbol-change.sh
> >> > index 8da7650..d5fad04 100755
> >> > --- a/devtools/check-symbol-change.sh
> >> > +++ b/devtools/check-symbol-change.sh
> >> > @@ -32,6 +32,7 @@ build_map_changes()
> >> > # symbol rule below
> >> > /^.*{/ {
> >> > gsub("+", "");
> >> > + gsub("-", "");
> >> > if (in_map == 1) {
> >> > sec=$(NF-1); in_sec=1;
> >> > }
> >> > --
> >> > 1.8.3.1
> >> >
> >> >
> >> Don't you also need to add some logic in the symbol detection match rule
> >> to
> >> print an appropriate indicator that a symbol is being removed? With just
> >> this
> >> change, you will note that you are parsing a section, but you will never
> >> trigger
> >> a symbol match
> >>
> >
> > I do remember seeing a warning about the "-EXPERIMENTAL" section.
> > And this is why I added this.
> > But since then I reorganised my series and eliminated some parts... so you
> > are most likely right.
> > I will double check and repost.
> >
> >
> Yes, you are right, I moved this out of another patch that I ended up not
> sending.
> But it makes no sense by itself.
> I will drop this in v2.
>
> Any comments on the other patches ?
> Thanks Neil.
>
No, I don't think I do, thanks for checking though!
Neil
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: update release notes for timer library changes
@ 2019-05-06 21:29 10% Erik Gabriel Carrillo
2019-05-06 21:29 10% ` Erik Gabriel Carrillo
0 siblings, 1 reply; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-06 21:29 UTC (permalink / raw)
To: john.mcnamara; +Cc: dev
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 5044ac7..f4457ac 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -266,6 +266,11 @@ API Changes
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+* timer: Functions have been introduced that allow multiple instances of the
+ timer lists to be created, and they are now allocated in shared memory. New
+ functions allow particular timer lists to be selected when timers are being
+ started, stopped, and managed.
+
ABI Changes
-----------
@@ -296,6 +301,9 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* timer: ``rte_timer_subsystem_init`` now returns success or failure to reflect
+ whether it was able to allocate memory.
+
Shared Library Versions
-----------------------
--
2.6.4
^ permalink raw reply [relevance 10%]
* [dpdk-dev] [PATCH] doc: update release notes for timer library changes
2019-05-06 21:29 10% [dpdk-dev] [PATCH] doc: update release notes for timer library changes Erik Gabriel Carrillo
@ 2019-05-06 21:29 10% ` Erik Gabriel Carrillo
0 siblings, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-06 21:29 UTC (permalink / raw)
To: john.mcnamara; +Cc: dev
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 5044ac7..f4457ac 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -266,6 +266,11 @@ API Changes
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+* timer: Functions have been introduced that allow multiple instances of the
+ timer lists to be created, and they are now allocated in shared memory. New
+ functions allow particular timer lists to be selected when timers are being
+ started, stopped, and managed.
+
ABI Changes
-----------
@@ -296,6 +301,9 @@ ABI Changes
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
layout and alignment.
+* timer: ``rte_timer_subsystem_init`` now returns success or failure to reflect
+ whether it was able to allocate memory.
+
Shared Library Versions
-----------------------
--
2.6.4
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-04-29 17:19 4% ` Ferruh Yigit
2019-04-29 17:19 4% ` Ferruh Yigit
@ 2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-08 11:07 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Arnon Warshavsky @ 2019-05-07 9:57 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Stephen Hemminger, dev, Thomas Monjalon, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
>
>
> Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
> perhaps it would be a problem if the content of the fifo changed but it is
> not
> the case.
>
Should I move this patch to deferred or reject?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-07 9:57 4% ` Arnon Warshavsky
@ 2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-08 11:07 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Arnon Warshavsky @ 2019-05-07 9:57 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Stephen Hemminger, dev, Thomas Monjalon, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
>
>
> Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
> perhaps it would be a problem if the content of the fifo changed but it is
> not
> the case.
>
Should I move this patch to deferred or reject?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
@ 2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 23:01 3% ` Carrillo, Erik G
0 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-08 8:49 UTC (permalink / raw)
To: Carrillo, Erik G, rsanford, thomas; +Cc: dev
On 07-May-19 11:04 PM, Carrillo, Erik G wrote:
> Hi Anatoly,
>
> Thanks for the review. Comments in-line:
>
> <...snipped...>
>
>>> #define RTE_MAX_DATA_ELS 64
>>> +static const struct rte_memzone *rte_timer_data_mz; static
>>> +rte_atomic16_t *rte_timer_mz_refcnt;
>>> static struct rte_timer_data *rte_timer_data_arr;
>>> static const uint32_t default_data_id;
>>> static uint32_t rte_timer_subsystem_initialized; @@ -155,6 +157,7 @@
>>> rte_timer_subsystem_init_v1905(void)
>>> struct rte_timer_data *data;
>>> int i, lcore_id;
>>> static const char *mz_name = "rte_timer_mz";
>>> + size_t data_arr_size = RTE_MAX_DATA_ELS *
>>> +sizeof(*rte_timer_data_arr);
>>
>> nitpicking, but... const?
>>
>
> No problem - I'll make this change if this line persists into the next version.
>
> <...snipped...>
>
>>>
>>> @@ -205,8 +216,11 @@
>> BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
>>> void __rte_experimental
>>> rte_timer_subsystem_finalize(void)
>>> {
>>> - if (rte_timer_data_arr)
>>> - rte_free(rte_timer_data_arr);
>>> + if (!rte_timer_subsystem_initialized)
>>> + return;
>>> +
>>> + if (rte_atomic16_dec_and_test(rte_timer_mz_refcnt))
>>> + rte_memzone_free(rte_timer_data_mz);
>>
>> I think there's a race here. You may get preempted after test but before
>> free, where another secondary could initialize. As far as i know, we also
>
> Indeed, thanks for catching this.
>
>> support a case when secondary initializes after primary stops running.
>>
>> Let's even suppose that we allow secondary processes to initialize the timer
>> subsystem by reserving memzone and checking rte_errno. You would still
>> have a chance of two init/deinit conflicting, because there's a hole between
>> memzone allocation and atomic increment.
>>
>> I don't think this race can be resolved in a safe way, so we might just have to
>> settle for a memory leak.
>>
>
> I don't see a solution here currently either. I'll look at removing the memzone_free()
> call and possibly the rte_timer_subsystem_finalize() API, since it seems like
> there's no reason for it to exist if it can't free the allocations.
I wonder if there are other places in DPDK where this pattern is used.
Technically, this kind of thing /could/ be resolved by having something
in our multiprocess shared memory outside of DPDK heap. I.e. store
something in rte_eal_memconfig like some other things do. This change,
however, would require an ABI break, so while changing this particular
API won't need a deprecation notice, the change itself would.
>
> Regards,
> Erik
>
>>>
>>> rte_timer_subsystem_initialized = 0;
>>> }
>>>
>>
>>
>> --
>> Thanks,
>> Anatoly
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
2019-05-08 8:49 3% ` Burakov, Anatoly
@ 2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 23:01 3% ` Carrillo, Erik G
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-08 8:49 UTC (permalink / raw)
To: Carrillo, Erik G, rsanford, thomas; +Cc: dev
On 07-May-19 11:04 PM, Carrillo, Erik G wrote:
> Hi Anatoly,
>
> Thanks for the review. Comments in-line:
>
> <...snipped...>
>
>>> #define RTE_MAX_DATA_ELS 64
>>> +static const struct rte_memzone *rte_timer_data_mz; static
>>> +rte_atomic16_t *rte_timer_mz_refcnt;
>>> static struct rte_timer_data *rte_timer_data_arr;
>>> static const uint32_t default_data_id;
>>> static uint32_t rte_timer_subsystem_initialized; @@ -155,6 +157,7 @@
>>> rte_timer_subsystem_init_v1905(void)
>>> struct rte_timer_data *data;
>>> int i, lcore_id;
>>> static const char *mz_name = "rte_timer_mz";
>>> + size_t data_arr_size = RTE_MAX_DATA_ELS *
>>> +sizeof(*rte_timer_data_arr);
>>
>> nitpicking, but... const?
>>
>
> No problem - I'll make this change if this line persists into the next version.
>
> <...snipped...>
>
>>>
>>> @@ -205,8 +216,11 @@
>> BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
>>> void __rte_experimental
>>> rte_timer_subsystem_finalize(void)
>>> {
>>> - if (rte_timer_data_arr)
>>> - rte_free(rte_timer_data_arr);
>>> + if (!rte_timer_subsystem_initialized)
>>> + return;
>>> +
>>> + if (rte_atomic16_dec_and_test(rte_timer_mz_refcnt))
>>> + rte_memzone_free(rte_timer_data_mz);
>>
>> I think there's a race here. You may get preempted after test but before
>> free, where another secondary could initialize. As far as i know, we also
>
> Indeed, thanks for catching this.
>
>> support a case when secondary initializes after primary stops running.
>>
>> Let's even suppose that we allow secondary processes to initialize the timer
>> subsystem by reserving memzone and checking rte_errno. You would still
>> have a chance of two init/deinit conflicting, because there's a hole between
>> memzone allocation and atomic increment.
>>
>> I don't think this race can be resolved in a safe way, so we might just have to
>> settle for a memory leak.
>>
>
> I don't see a solution here currently either. I'll look at removing the memzone_free()
> call and possibly the rte_timer_subsystem_finalize() API, since it seems like
> there's no reason for it to exist if it can't free the allocations.
I wonder if there are other places in DPDK where this pattern is used.
Technically, this kind of thing /could/ be resolved by having something
in our multiprocess shared memory outside of DPDK heap. I.e. store
something in rte_eal_memconfig like some other things do. This change,
however, would require an ABI break, so while changing this particular
API won't need a deprecation notice, the change itself would.
>
> Regards,
> Erik
>
>>>
>>> rte_timer_subsystem_initialized = 0;
>>> }
>>>
>>
>>
>> --
>> Thanks,
>> Anatoly
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-07 9:57 4% ` Arnon Warshavsky
@ 2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 20:22 4% ` Arnon Warshavsky
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-05-08 11:07 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
07/05/2019 11:57, Arnon Warshavsky:
> >
> >
> > Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
> > perhaps it would be a problem if the content of the fifo changed but it is
> > not
> > the case.
> >
>
> Should I move this patch to deferred or reject?
It can be set to "rejected".
I am preparing a deprecation notice for rte_eal_remote_launch
and rte_metrics_init.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-08 11:07 4% ` Thomas Monjalon
@ 2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 20:22 4% ` Arnon Warshavsky
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-08 11:07 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
07/05/2019 11:57, Arnon Warshavsky:
> >
> >
> > Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
> > perhaps it would be a problem if the content of the fifo changed but it is
> > not
> > the case.
> >
>
> Should I move this patch to deferred or reject?
It can be set to "rejected".
I am preparing a deprecation notice for rte_eal_remote_launch
and rte_metrics_init.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 11:07 4% ` Thomas Monjalon
@ 2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:25 4% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Arnon Warshavsky @ 2019-05-08 20:22 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
>
>
>
> I am preparing a deprecation notice for rte_eal_remote_launch
> and rte_metrics_init.
>
>
> hmm, I followed panic and not exit, so missed rte_metrics_init.
rte_eal_remote_launch currently returns int. what deprecation goes there?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-08 20:22 4% ` Arnon Warshavsky
@ 2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:25 4% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Arnon Warshavsky @ 2019-05-08 20:22 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
>
>
>
> I am preparing a deprecation notice for rte_eal_remote_launch
> and rte_metrics_init.
>
>
> hmm, I followed panic and not exit, so missed rte_metrics_init.
rte_eal_remote_launch currently returns int. what deprecation goes there?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:22 4% ` Arnon Warshavsky
@ 2019-05-08 20:25 4% ` Thomas Monjalon
2019-05-08 20:25 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-05-08 20:25 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
08/05/2019 22:22, Arnon Warshavsky:
> > I am preparing a deprecation notice for rte_eal_remote_launch
> > and rte_metrics_init.
> >
> hmm, I followed panic and not exit, so missed rte_metrics_init.
> rte_eal_remote_launch currently returns int. what deprecation goes there?
We probably need to add a new error code for rte_eal_remote_launch.
It is just a doxygen change, but it is part of the API.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni
2019-05-08 20:25 4% ` Thomas Monjalon
@ 2019-05-08 20:25 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-08 20:25 UTC (permalink / raw)
To: Arnon Warshavsky
Cc: dev, Ferruh Yigit, Stephen Hemminger, Burakov, Anatoly, Lu,
Wenzhuo, Doherty, Declan, Jerin Jacob, Bruce Richardson,
ranjit.menon, anand.rawat, Pallavi Kadam, Harini Ramakrishnan,
O'Hare, Cathal, Arnon Warshavsky
08/05/2019 22:22, Arnon Warshavsky:
> > I am preparing a deprecation notice for rte_eal_remote_launch
> > and rte_metrics_init.
> >
> hmm, I followed panic and not exit, so missed rte_metrics_init.
> rte_eal_remote_launch currently returns int. what deprecation goes there?
We probably need to add a new error code for rte_eal_remote_launch.
It is just a doxygen change, but it is part of the API.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
@ 2019-05-08 22:48 8% Erik Gabriel Carrillo
2019-05-08 22:48 8% ` Erik Gabriel Carrillo
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-08 22:48 UTC (permalink / raw)
To: thomas; +Cc: anatoly.burakov, dev
Due to an upcoming fix to allow the timer library to safely free its
allocations during the finalize() call[1], an ABI change will be
required. A new lock will be added to the rte_mem_config structure,
which will be used by the timer library to synchronize init/finalize
calls among multiple processes.
[1] http://patches.dpdk.org/patch/53334/
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,10 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: the ``rte_mem_config`` struct will change to include a new lock that
+ will allow the timer subsystem to safely release its allocations at cleanup
+ time. This will result in an ABI break.
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
--
2.6.4
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-08 22:48 8% [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup Erik Gabriel Carrillo
@ 2019-05-08 22:48 8% ` Erik Gabriel Carrillo
2019-05-09 1:11 3% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-08 22:48 UTC (permalink / raw)
To: thomas; +Cc: anatoly.burakov, dev
Due to an upcoming fix to allow the timer library to safely free its
allocations during the finalize() call[1], an ABI change will be
required. A new lock will be added to the rte_mem_config structure,
which will be used by the timer library to synchronize init/finalize
calls among multiple processes.
[1] http://patches.dpdk.org/patch/53334/
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,10 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: the ``rte_mem_config`` struct will change to include a new lock that
+ will allow the timer subsystem to safely release its allocations at cleanup
+ time. This will result in an ABI break.
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
--
2.6.4
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 8:49 3% ` Burakov, Anatoly
@ 2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-09 7:44 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Carrillo, Erik G @ 2019-05-08 23:01 UTC (permalink / raw)
To: Burakov, Anatoly, rsanford, thomas; +Cc: dev
> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Wednesday, May 8, 2019 3:50 AM
> To: Carrillo, Erik G <erik.g.carrillo@intel.com>; rsanford@akamai.com;
> thomas@monjalon.net
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2] timer: fix resource leak in finalize
>
> On 07-May-19 11:04 PM, Carrillo, Erik G wrote:
> > Hi Anatoly,
> >
> > Thanks for the review. Comments in-line:
> >
> > <...snipped...>
> >
> >>> #define RTE_MAX_DATA_ELS 64
> >>> +static const struct rte_memzone *rte_timer_data_mz; static
> >>> +rte_atomic16_t *rte_timer_mz_refcnt;
> >>> static struct rte_timer_data *rte_timer_data_arr;
> >>> static const uint32_t default_data_id;
> >>> static uint32_t rte_timer_subsystem_initialized; @@ -155,6 +157,7
> >>> @@
> >>> rte_timer_subsystem_init_v1905(void)
> >>> struct rte_timer_data *data;
> >>> int i, lcore_id;
> >>> static const char *mz_name = "rte_timer_mz";
> >>> + size_t data_arr_size = RTE_MAX_DATA_ELS *
> >>> +sizeof(*rte_timer_data_arr);
> >>
> >> nitpicking, but... const?
> >>
> >
> > No problem - I'll make this change if this line persists into the next version.
> >
> > <...snipped...>
> >
> >>>
> >>> @@ -205,8 +216,11 @@
> >> BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
> >>> void __rte_experimental
> >>> rte_timer_subsystem_finalize(void)
> >>> {
> >>> - if (rte_timer_data_arr)
> >>> - rte_free(rte_timer_data_arr);
> >>> + if (!rte_timer_subsystem_initialized)
> >>> + return;
> >>> +
> >>> + if (rte_atomic16_dec_and_test(rte_timer_mz_refcnt))
> >>> + rte_memzone_free(rte_timer_data_mz);
> >>
> >> I think there's a race here. You may get preempted after test but
> >> before free, where another secondary could initialize. As far as i
> >> know, we also
> >
> > Indeed, thanks for catching this.
> >
> >> support a case when secondary initializes after primary stops running.
> >>
> >> Let's even suppose that we allow secondary processes to initialize
> >> the timer subsystem by reserving memzone and checking rte_errno. You
> >> would still have a chance of two init/deinit conflicting, because
> >> there's a hole between memzone allocation and atomic increment.
> >>
> >> I don't think this race can be resolved in a safe way, so we might
> >> just have to settle for a memory leak.
> >>
> >
> > I don't see a solution here currently either. I'll look at removing
> > the memzone_free() call and possibly the
> > rte_timer_subsystem_finalize() API, since it seems like there's no reason
> for it to exist if it can't free the allocations.
>
> I wonder if there are other places in DPDK where this pattern is used.
>
> Technically, this kind of thing /could/ be resolved by having something in our
> multiprocess shared memory outside of DPDK heap. I.e. store something in
> rte_eal_memconfig like some other things do. This change, however, would
> require an ABI break, so while changing this particular API won't need a
> deprecation notice, the change itself would.
I like this idea; thanks for the suggestion. I went ahead and submitted a new version
of this patch with this approach. It's dependent on one other new patch that allows
secondary processes to reserve the memzone. I also submitted a deprecation
notice for the ABI break for the change to rte_mem_config.
Thomas, I suspect that I should mark v3 of this patch as "deferred", so I've gone ahead and
done that, but let me know if that's wrong.
Thanks,
Erik
>
> >
> > Regards,
> > Erik
> >
> >>>
> >>> rte_timer_subsystem_initialized = 0;
> >>> }
> >>>
> >>
> >>
> >> --
> >> Thanks,
> >> Anatoly
>
>
> --
> Thanks,
> Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
2019-05-08 23:01 3% ` Carrillo, Erik G
@ 2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-09 7:44 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Carrillo, Erik G @ 2019-05-08 23:01 UTC (permalink / raw)
To: Burakov, Anatoly, rsanford, thomas; +Cc: dev
> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Wednesday, May 8, 2019 3:50 AM
> To: Carrillo, Erik G <erik.g.carrillo@intel.com>; rsanford@akamai.com;
> thomas@monjalon.net
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2] timer: fix resource leak in finalize
>
> On 07-May-19 11:04 PM, Carrillo, Erik G wrote:
> > Hi Anatoly,
> >
> > Thanks for the review. Comments in-line:
> >
> > <...snipped...>
> >
> >>> #define RTE_MAX_DATA_ELS 64
> >>> +static const struct rte_memzone *rte_timer_data_mz; static
> >>> +rte_atomic16_t *rte_timer_mz_refcnt;
> >>> static struct rte_timer_data *rte_timer_data_arr;
> >>> static const uint32_t default_data_id;
> >>> static uint32_t rte_timer_subsystem_initialized; @@ -155,6 +157,7
> >>> @@
> >>> rte_timer_subsystem_init_v1905(void)
> >>> struct rte_timer_data *data;
> >>> int i, lcore_id;
> >>> static const char *mz_name = "rte_timer_mz";
> >>> + size_t data_arr_size = RTE_MAX_DATA_ELS *
> >>> +sizeof(*rte_timer_data_arr);
> >>
> >> nitpicking, but... const?
> >>
> >
> > No problem - I'll make this change if this line persists into the next version.
> >
> > <...snipped...>
> >
> >>>
> >>> @@ -205,8 +216,11 @@
> >> BIND_DEFAULT_SYMBOL(rte_timer_subsystem_init, _v1905, 19.05);
> >>> void __rte_experimental
> >>> rte_timer_subsystem_finalize(void)
> >>> {
> >>> - if (rte_timer_data_arr)
> >>> - rte_free(rte_timer_data_arr);
> >>> + if (!rte_timer_subsystem_initialized)
> >>> + return;
> >>> +
> >>> + if (rte_atomic16_dec_and_test(rte_timer_mz_refcnt))
> >>> + rte_memzone_free(rte_timer_data_mz);
> >>
> >> I think there's a race here. You may get preempted after test but
> >> before free, where another secondary could initialize. As far as i
> >> know, we also
> >
> > Indeed, thanks for catching this.
> >
> >> support a case when secondary initializes after primary stops running.
> >>
> >> Let's even suppose that we allow secondary processes to initialize
> >> the timer subsystem by reserving memzone and checking rte_errno. You
> >> would still have a chance of two init/deinit conflicting, because
> >> there's a hole between memzone allocation and atomic increment.
> >>
> >> I don't think this race can be resolved in a safe way, so we might
> >> just have to settle for a memory leak.
> >>
> >
> > I don't see a solution here currently either. I'll look at removing
> > the memzone_free() call and possibly the
> > rte_timer_subsystem_finalize() API, since it seems like there's no reason
> for it to exist if it can't free the allocations.
>
> I wonder if there are other places in DPDK where this pattern is used.
>
> Technically, this kind of thing /could/ be resolved by having something in our
> multiprocess shared memory outside of DPDK heap. I.e. store something in
> rte_eal_memconfig like some other things do. This change, however, would
> require an ABI break, so while changing this particular API won't need a
> deprecation notice, the change itself would.
I like this idea; thanks for the suggestion. I went ahead and submitted a new version
of this patch with this approach. It's dependent on one other new patch that allows
secondary processes to reserve the memzone. I also submitted a deprecation
notice for the ABI break for the change to rte_mem_config.
Thomas, I suspect that I should mark v3 of this patch as "deferred", so I've gone ahead and
done that, but let me know if that's wrong.
Thanks,
Erik
>
> >
> > Regards,
> > Erik
> >
> >>>
> >>> rte_timer_subsystem_initialized = 0;
> >>> }
> >>>
> >>
> >>
> >> --
> >> Thanks,
> >> Anatoly
>
>
> --
> Thanks,
> Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-08 22:48 8% [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup Erik Gabriel Carrillo
2019-05-08 22:48 8% ` Erik Gabriel Carrillo
@ 2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 7:05 0% ` David Marchand
2019-05-09 11:53 0% ` Burakov, Anatoly
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
3 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-05-09 1:11 UTC (permalink / raw)
To: Erik Gabriel Carrillo; +Cc: thomas, anatoly.burakov, dev
On Wed, 8 May 2019 17:48:06 -0500
Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
>
> [1] http://patches.dpdk.org/patch/53334/
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,10 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will change to include a new lock that
> + will allow the timer subsystem to safely release its allocations at cleanup
> + time. This will result in an ABI break.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
NAK
Please go to the effort of making rte_mem_config not part of the visible ABI.
Then change it.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 1:11 3% ` Stephen Hemminger
@ 2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 7:05 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-09 1:11 UTC (permalink / raw)
To: Erik Gabriel Carrillo; +Cc: thomas, anatoly.burakov, dev
On Wed, 8 May 2019 17:48:06 -0500
Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
>
> [1] http://patches.dpdk.org/patch/53334/
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,10 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will change to include a new lock that
> + will allow the timer subsystem to safely release its allocations at cleanup
> + time. This will result in an ABI break.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
NAK
Please go to the effort of making rte_mem_config not part of the visible ABI.
Then change it.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 1:11 3% ` Stephen Hemminger
@ 2019-05-09 7:05 0% ` David Marchand
2019-05-09 7:05 0% ` David Marchand
2019-05-09 8:33 4% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: David Marchand @ 2019-05-09 7:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Erik Gabriel Carrillo, Thomas Monjalon, Burakov, Anatoly, dev
On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger <stephen@networkplumber.org>
wrote:
> On Wed, 8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> > + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a new lock
> that
> > + will allow the timer subsystem to safely release its allocations at
> cleanup
> > + time. This will result in an ABI break.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the visible
> ABI.
> Then change it.
>
+1.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 7:05 0% ` David Marchand
@ 2019-05-09 7:05 0% ` David Marchand
2019-05-09 8:33 4% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-05-09 7:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Erik Gabriel Carrillo, Thomas Monjalon, Burakov, Anatoly, dev
On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger <stephen@networkplumber.org>
wrote:
> On Wed, 8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@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 b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> > + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a new lock
> that
> > + will allow the timer subsystem to safely release its allocations at
> cleanup
> > + time. This will result in an ABI break.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the visible
> ABI.
> Then change it.
>
+1.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-08 23:01 3% ` Carrillo, Erik G
@ 2019-05-09 7:44 0% ` Thomas Monjalon
2019-05-09 7:44 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-05-09 7:44 UTC (permalink / raw)
To: Carrillo, Erik G; +Cc: Burakov, Anatoly, rsanford, dev
09/05/2019 01:01, Carrillo, Erik G:
> I like this idea; thanks for the suggestion. I went ahead and submitted a new version
> of this patch with this approach. It's dependent on one other new patch that allows
> secondary processes to reserve the memzone. I also submitted a deprecation
> notice for the ABI break for the change to rte_mem_config.
>
> Thomas, I suspect that I should mark v3 of this patch as "deferred", so I've gone ahead and
> done that, but let me know if that's wrong.
Any patch targetting 19.08 should be marked as deferred, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] timer: fix resource leak in finalize
2019-05-09 7:44 0% ` Thomas Monjalon
@ 2019-05-09 7:44 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-09 7:44 UTC (permalink / raw)
To: Carrillo, Erik G; +Cc: Burakov, Anatoly, rsanford, dev
09/05/2019 01:01, Carrillo, Erik G:
> I like this idea; thanks for the suggestion. I went ahead and submitted a new version
> of this patch with this approach. It's dependent on one other new patch that allows
> secondary processes to reserve the memzone. I also submitted a deprecation
> notice for the ABI break for the change to rte_mem_config.
>
> Thomas, I suspect that I should mark v3 of this patch as "deferred", so I've gone ahead and
> done that, but let me know if that's wrong.
Any patch targetting 19.08 should be marked as deferred, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] timer: fix resource leak in finalize
@ 2019-05-09 8:29 3% ` Burakov, Anatoly
2019-05-09 8:29 3% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-05-09 8:29 UTC (permalink / raw)
To: Erik Gabriel Carrillo, rsanford, thomas; +Cc: dev
On 08-May-19 11:35 PM, Erik Gabriel Carrillo wrote:
> By using a lock added to the rte_mem_config (which lives in shared
> memory), we can synchronize multiple processes in init/finalize and
> safely free allocations made during init.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v3:
> - The previous version had race condition. This version fixes the race
> by adding a lock in shared memory outside of the DPDK heap area
> that can be used to safely free the memzone reserved in the subsystem
> init call. (Anatoly)
>
> This patch depends on http://patches.dpdk.org/patch/53333/.
>
> changes in v2:
> - Handle scenario where primary process exits before secondaries such
> that memzone is not freed early (Anatoly)
>
> lib/librte_eal/common/include/rte_eal_memconfig.h | 3 +++
> lib/librte_timer/rte_timer.c | 23 ++++++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h
> index 84aabe3..8cbc09c 100644
> --- a/lib/librte_eal/common/include/rte_eal_memconfig.h
> +++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
> @@ -64,6 +64,9 @@ struct rte_mem_config {
> rte_rwlock_t memory_hotplug_lock;
> /**< indicates whether memory hotplug request is in progress. */
>
> + rte_spinlock_t timer_subsystem_lock;
> + /**< indicates whether timer subsystem init/finalize is in progress. */
> +
I believe there's an initialize function somewhere which will initialize
all of these locks. This lock should be in there as well.
Other than that, i'm OK with this change, however i feel like /just/
adding this would be a missed opportunity, because next time we want to
add something here it will be an ABI break again.
We could perhaps use this opportunity to leave some padding for future
data. I'm not sure how would that look like, just an idea floating in my
head :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] timer: fix resource leak in finalize
2019-05-09 8:29 3% ` Burakov, Anatoly
@ 2019-05-09 8:29 3% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 8:29 UTC (permalink / raw)
To: Erik Gabriel Carrillo, rsanford, thomas; +Cc: dev
On 08-May-19 11:35 PM, Erik Gabriel Carrillo wrote:
> By using a lock added to the rte_mem_config (which lives in shared
> memory), we can synchronize multiple processes in init/finalize and
> safely free allocations made during init.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v3:
> - The previous version had race condition. This version fixes the race
> by adding a lock in shared memory outside of the DPDK heap area
> that can be used to safely free the memzone reserved in the subsystem
> init call. (Anatoly)
>
> This patch depends on http://patches.dpdk.org/patch/53333/.
>
> changes in v2:
> - Handle scenario where primary process exits before secondaries such
> that memzone is not freed early (Anatoly)
>
> lib/librte_eal/common/include/rte_eal_memconfig.h | 3 +++
> lib/librte_timer/rte_timer.c | 23 ++++++++++++++++++++++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h
> index 84aabe3..8cbc09c 100644
> --- a/lib/librte_eal/common/include/rte_eal_memconfig.h
> +++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
> @@ -64,6 +64,9 @@ struct rte_mem_config {
> rte_rwlock_t memory_hotplug_lock;
> /**< indicates whether memory hotplug request is in progress. */
>
> + rte_spinlock_t timer_subsystem_lock;
> + /**< indicates whether timer subsystem init/finalize is in progress. */
> +
I believe there's an initialize function somewhere which will initialize
all of these locks. This lock should be in there as well.
Other than that, i'm OK with this change, however i feel like /just/
adding this would be a missed opportunity, because next time we want to
add something here it will be an ABI break again.
We could perhaps use this opportunity to leave some padding for future
data. I'm not sure how would that look like, just an idea floating in my
head :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 7:05 0% ` David Marchand
2019-05-09 7:05 0% ` David Marchand
@ 2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 9:06 3% ` Bruce Richardson
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 8:33 UTC (permalink / raw)
To: David Marchand, Stephen Hemminger
Cc: Erik Gabriel Carrillo, Thomas Monjalon, dev
On 09-May-19 8:05 AM, David Marchand wrote:
> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>
> On Wed, 8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> <mailto:erik.g.carrillo@intel.com>> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> > + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a
> new lock that
> > + will allow the timer subsystem to safely release its
> allocations at cleanup
> > + time. This will result in an ABI break.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and
> ``rte_vfio_dma_unmap`` APIs which
> > have been replaced with ``rte_dev_dma_map`` and
> ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the
> visible ABI.
> Then change it.
>
>
> +1.
I agree on principle, however this won't solve the issue. It doesn't
need to be externally visible, but that's not all of its problems - it's
also shared between processes so there's an ABI contract between primary
and secondary too. This means that, even if the structure itself is not
public, any changes to it will still result in an ABI break. That's the
nature of our shared memory.
In other words, if your goal is to avoid ABI breaks on changing this
structure, making it internal won't help in the slightest.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 8:33 4% ` Burakov, Anatoly
@ 2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 9:06 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 8:33 UTC (permalink / raw)
To: David Marchand, Stephen Hemminger
Cc: Erik Gabriel Carrillo, Thomas Monjalon, dev
On 09-May-19 8:05 AM, David Marchand wrote:
> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>
> On Wed, 8 May 2019 17:48:06 -0500
> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> <mailto:erik.g.carrillo@intel.com>> wrote:
>
> > Due to an upcoming fix to allow the timer library to safely free its
> > allocations during the finalize() call[1], an ABI change will be
> > required. A new lock will be added to the rte_mem_config structure,
> > which will be used by the timer library to synchronize init/finalize
> > calls among multiple processes.
> >
> > [1] http://patches.dpdk.org/patch/53334/
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,10 @@ Deprecation Notices
> >
> > + ``rte_eal_devargs_type_count``
> >
> > +* eal: the ``rte_mem_config`` struct will change to include a
> new lock that
> > + will allow the timer subsystem to safely release its
> allocations at cleanup
> > + time. This will result in an ABI break.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and
> ``rte_vfio_dma_unmap`` APIs which
> > have been replaced with ``rte_dev_dma_map`` and
> ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
>
> NAK
>
> Please go to the effort of making rte_mem_config not part of the
> visible ABI.
> Then change it.
>
>
> +1.
I agree on principle, however this won't solve the issue. It doesn't
need to be externally visible, but that's not all of its problems - it's
also shared between processes so there's an ABI contract between primary
and secondary too. This means that, even if the structure itself is not
public, any changes to it will still result in an ABI break. That's the
nature of our shared memory.
In other words, if your goal is to avoid ABI breaks on changing this
structure, making it internal won't help in the slightest.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 8:33 4% ` Burakov, Anatoly
@ 2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:37 0% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2019-05-09 9:06 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: David Marchand, Stephen Hemminger, Erik Gabriel Carrillo,
Thomas Monjalon, dev
On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 8:05 AM, David Marchand wrote:
> > On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> > <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >
> > On Wed, 8 May 2019 17:48:06 -0500
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> > <mailto:erik.g.carrillo@intel.com>> wrote:
> >
> > > Due to an upcoming fix to allow the timer library to safely free its
> > > allocations during the finalize() call[1], an ABI change will be
> > > required. A new lock will be added to the rte_mem_config structure,
> > > which will be used by the timer library to synchronize init/finalize
> > > calls among multiple processes.
> > >
> > > [1] http://patches.dpdk.org/patch/53334/
> > >
> > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> > <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -31,6 +31,10 @@ Deprecation Notices
> > >
> > > + ``rte_eal_devargs_type_count``
> > >
> > > +* eal: the ``rte_mem_config`` struct will change to include a
> > new lock that
> > > + will allow the timer subsystem to safely release its
> > allocations at cleanup
> > > + time. This will result in an ABI break.
> > > +
> > > * vfio: removal of ``rte_vfio_dma_map`` and
> > ``rte_vfio_dma_unmap`` APIs which
> > > have been replaced with ``rte_dev_dma_map`` and
> > ``rte_dev_dma_unmap``
> > > functions. The due date for the removal targets DPDK 20.02.
> >
> > NAK
> >
> > Please go to the effort of making rte_mem_config not part of the
> > visible ABI.
> > Then change it.
> >
> >
> > +1.
>
> I agree on principle, however this won't solve the issue. It doesn't need to
> be externally visible, but that's not all of its problems - it's also shared
> between processes so there's an ABI contract between primary and secondary
> too. This means that, even if the structure itself is not public, any
> changes to it will still result in an ABI break. That's the nature of our
> shared memory.
>
> In other words, if your goal is to avoid ABI breaks on changing this
> structure, making it internal won't help in the slightest.
>
Is there an ABI contract between primary and secondary. I always assumed
that if using secondary processes the requirement (though undocumented) was
that both had to be linked against the exact same versions of DPDK?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:06 3% ` Bruce Richardson
@ 2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:37 0% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2019-05-09 9:06 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: David Marchand, Stephen Hemminger, Erik Gabriel Carrillo,
Thomas Monjalon, dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2901 bytes --]
On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 8:05 AM, David Marchand wrote:
> > On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> > <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >
> > On Wed, 8 May 2019 17:48:06 -0500
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> > <mailto:erik.g.carrillo@intel.com>> wrote:
> >
> > > Due to an upcoming fix to allow the timer library to safely free its
> > > allocations during the finalize() call[1], an ABI change will be
> > > required. A new lock will be added to the rte_mem_config structure,
> > > which will be used by the timer library to synchronize init/finalize
> > > calls among multiple processes.
> > >
> > > [1] http://patches.dpdk.org/patch/53334/
> > >
> > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> > <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -31,6 +31,10 @@ Deprecation Notices
> > >
> > > + ``rte_eal_devargs_type_count``
> > >
> > > +* eal: the ``rte_mem_config`` struct will change to include a
> > new lock that
> > > + will allow the timer subsystem to safely release its
> > allocations at cleanup
> > > + time. This will result in an ABI break.
> > > +
> > > * vfio: removal of ``rte_vfio_dma_map`` and
> > ``rte_vfio_dma_unmap`` APIs which
> > > have been replaced with ``rte_dev_dma_map`` and
> > ``rte_dev_dma_unmap``
> > > functions. The due date for the removal targets DPDK 20.02.
> >
> > NAK
> >
> > Please go to the effort of making rte_mem_config not part of the
> > visible ABI.
> > Then change it.
> >
> >
> > +1.
>
> I agree on principle, however this won't solve the issue. It doesn't need to
> be externally visible, but that's not all of its problems - it's also shared
> between processes so there's an ABI contract between primary and secondary
> too. This means that, even if the structure itself is not public, any
> changes to it will still result in an ABI break. That's the nature of our
> shared memory.
>
> In other words, if your goal is to avoid ABI breaks on changing this
> structure, making it internal won't help in the slightest.
>
Is there an ABI contract between primary and secondary. I always assumed
that if using secondary processes the requirement (though undocumented) was
that both had to be linked against the exact same versions of DPDK?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:06 3% ` Bruce Richardson
@ 2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:38 0% ` Thomas Monjalon
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 9:37 UTC (permalink / raw)
To: Bruce Richardson
Cc: David Marchand, Stephen Hemminger, Erik Gabriel Carrillo,
Thomas Monjalon, dev
On 09-May-19 10:06 AM, Bruce Richardson wrote:
> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>> On 09-May-19 8:05 AM, David Marchand wrote:
>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>
>>> On Wed, 8 May 2019 17:48:06 -0500
>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>
>>> > Due to an upcoming fix to allow the timer library to safely free its
>>> > allocations during the finalize() call[1], an ABI change will be
>>> > required. A new lock will be added to the rte_mem_config structure,
>>> > which will be used by the timer library to synchronize init/finalize
>>> > calls among multiple processes.
>>> >
>>> > [1] http://patches.dpdk.org/patch/53334/
>>> >
>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>> >
>>> > + ``rte_eal_devargs_type_count``
>>> >
>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>> new lock that
>>> > + will allow the timer subsystem to safely release its
>>> allocations at cleanup
>>> > + time. This will result in an ABI break.
>>> > +
>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>> ``rte_vfio_dma_unmap`` APIs which
>>> > have been replaced with ``rte_dev_dma_map`` and
>>> ``rte_dev_dma_unmap``
>>> > functions. The due date for the removal targets DPDK 20.02.
>>>
>>> NAK
>>>
>>> Please go to the effort of making rte_mem_config not part of the
>>> visible ABI.
>>> Then change it.
>>>
>>>
>>> +1.
>>
>> I agree on principle, however this won't solve the issue. It doesn't need to
>> be externally visible, but that's not all of its problems - it's also shared
>> between processes so there's an ABI contract between primary and secondary
>> too. This means that, even if the structure itself is not public, any
>> changes to it will still result in an ABI break. That's the nature of our
>> shared memory.
>>
>> In other words, if your goal is to avoid ABI breaks on changing this
>> structure, making it internal won't help in the slightest.
>>
>
> Is there an ABI contract between primary and secondary. I always assumed
> that if using secondary processes the requirement (though undocumented) was
> that both had to be linked against the exact same versions of DPDK?
>
The fact that it's undocumented means we can't assume everyone will do
that :)
If the community agrees that primary/secondary processes should always
use the same DPDK version (regardless of static/dynamic builds etc.),
then this problem would probably be solved.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:37 0% ` Burakov, Anatoly
@ 2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:38 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 9:37 UTC (permalink / raw)
To: Bruce Richardson
Cc: David Marchand, Stephen Hemminger, Erik Gabriel Carrillo,
Thomas Monjalon, dev
On 09-May-19 10:06 AM, Bruce Richardson wrote:
> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>> On 09-May-19 8:05 AM, David Marchand wrote:
>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>
>>> On Wed, 8 May 2019 17:48:06 -0500
>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>
>>> > Due to an upcoming fix to allow the timer library to safely free its
>>> > allocations during the finalize() call[1], an ABI change will be
>>> > required. A new lock will be added to the rte_mem_config structure,
>>> > which will be used by the timer library to synchronize init/finalize
>>> > calls among multiple processes.
>>> >
>>> > [1] http://patches.dpdk.org/patch/53334/
>>> >
>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>> >
>>> > + ``rte_eal_devargs_type_count``
>>> >
>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>> new lock that
>>> > + will allow the timer subsystem to safely release its
>>> allocations at cleanup
>>> > + time. This will result in an ABI break.
>>> > +
>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>> ``rte_vfio_dma_unmap`` APIs which
>>> > have been replaced with ``rte_dev_dma_map`` and
>>> ``rte_dev_dma_unmap``
>>> > functions. The due date for the removal targets DPDK 20.02.
>>>
>>> NAK
>>>
>>> Please go to the effort of making rte_mem_config not part of the
>>> visible ABI.
>>> Then change it.
>>>
>>>
>>> +1.
>>
>> I agree on principle, however this won't solve the issue. It doesn't need to
>> be externally visible, but that's not all of its problems - it's also shared
>> between processes so there's an ABI contract between primary and secondary
>> too. This means that, even if the structure itself is not public, any
>> changes to it will still result in an ABI break. That's the nature of our
>> shared memory.
>>
>> In other words, if your goal is to avoid ABI breaks on changing this
>> structure, making it internal won't help in the slightest.
>>
>
> Is there an ABI contract between primary and secondary. I always assumed
> that if using secondary processes the requirement (though undocumented) was
> that both had to be linked against the exact same versions of DPDK?
>
The fact that it's undocumented means we can't assume everyone will do
that :)
If the community agrees that primary/secondary processes should always
use the same DPDK version (regardless of static/dynamic builds etc.),
then this problem would probably be solved.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:37 0% ` Burakov, Anatoly
@ 2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:50 0% ` Ray Kinsella
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-05-09 9:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
09/05/2019 11:37, Burakov, Anatoly:
> On 09-May-19 10:06 AM, Bruce Richardson wrote:
> > On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> >> On 09-May-19 8:05 AM, David Marchand wrote:
> >>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>
> >>> On Wed, 8 May 2019 17:48:06 -0500
> >>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>> <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>
> >>> > Due to an upcoming fix to allow the timer library to safely free its
> >>> > allocations during the finalize() call[1], an ABI change will be
> >>> > required. A new lock will be added to the rte_mem_config structure,
> >>> > which will be used by the timer library to synchronize init/finalize
> >>> > calls among multiple processes.
> >>> >
> >>> > [1] http://patches.dpdk.org/patch/53334/
> >>> >
> >>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> >>> > --- a/doc/guides/rel_notes/deprecation.rst
> >>> > +++ b/doc/guides/rel_notes/deprecation.rst
> >>> > @@ -31,6 +31,10 @@ Deprecation Notices
> >>> >
> >>> > + ``rte_eal_devargs_type_count``
> >>> >
> >>> > +* eal: the ``rte_mem_config`` struct will change to include a
> >>> new lock that
> >>> > + will allow the timer subsystem to safely release its
> >>> allocations at cleanup
> >>> > + time. This will result in an ABI break.
> >>> > +
> >>> > * vfio: removal of ``rte_vfio_dma_map`` and
> >>> ``rte_vfio_dma_unmap`` APIs which
> >>> > have been replaced with ``rte_dev_dma_map`` and
> >>> ``rte_dev_dma_unmap``
> >>> > functions. The due date for the removal targets DPDK 20.02.
> >>>
> >>> NAK
> >>>
> >>> Please go to the effort of making rte_mem_config not part of the
> >>> visible ABI.
> >>> Then change it.
> >>>
> >>>
> >>> +1.
> >>
> >> I agree on principle, however this won't solve the issue. It doesn't need to
> >> be externally visible, but that's not all of its problems - it's also shared
> >> between processes so there's an ABI contract between primary and secondary
> >> too. This means that, even if the structure itself is not public, any
> >> changes to it will still result in an ABI break. That's the nature of our
> >> shared memory.
> >>
> >> In other words, if your goal is to avoid ABI breaks on changing this
> >> structure, making it internal won't help in the slightest.
> >>
> >
> > Is there an ABI contract between primary and secondary. I always assumed
> > that if using secondary processes the requirement (though undocumented) was
> > that both had to be linked against the exact same versions of DPDK?
> >
>
> The fact that it's undocumented means we can't assume everyone will do
> that :)
>
> If the community agrees that primary/secondary processes should always
> use the same DPDK version (regardless of static/dynamic builds etc.),
> then this problem would probably be solved.
+1 to document that primary/secondary with different DPDK versions
is not supported.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:38 0% ` Thomas Monjalon
@ 2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:50 0% ` Ray Kinsella
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-09 9:38 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
09/05/2019 11:37, Burakov, Anatoly:
> On 09-May-19 10:06 AM, Bruce Richardson wrote:
> > On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> >> On 09-May-19 8:05 AM, David Marchand wrote:
> >>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>
> >>> On Wed, 8 May 2019 17:48:06 -0500
> >>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>> <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>
> >>> > Due to an upcoming fix to allow the timer library to safely free its
> >>> > allocations during the finalize() call[1], an ABI change will be
> >>> > required. A new lock will be added to the rte_mem_config structure,
> >>> > which will be used by the timer library to synchronize init/finalize
> >>> > calls among multiple processes.
> >>> >
> >>> > [1] http://patches.dpdk.org/patch/53334/
> >>> >
> >>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> >>> > --- a/doc/guides/rel_notes/deprecation.rst
> >>> > +++ b/doc/guides/rel_notes/deprecation.rst
> >>> > @@ -31,6 +31,10 @@ Deprecation Notices
> >>> >
> >>> > + ``rte_eal_devargs_type_count``
> >>> >
> >>> > +* eal: the ``rte_mem_config`` struct will change to include a
> >>> new lock that
> >>> > + will allow the timer subsystem to safely release its
> >>> allocations at cleanup
> >>> > + time. This will result in an ABI break.
> >>> > +
> >>> > * vfio: removal of ``rte_vfio_dma_map`` and
> >>> ``rte_vfio_dma_unmap`` APIs which
> >>> > have been replaced with ``rte_dev_dma_map`` and
> >>> ``rte_dev_dma_unmap``
> >>> > functions. The due date for the removal targets DPDK 20.02.
> >>>
> >>> NAK
> >>>
> >>> Please go to the effort of making rte_mem_config not part of the
> >>> visible ABI.
> >>> Then change it.
> >>>
> >>>
> >>> +1.
> >>
> >> I agree on principle, however this won't solve the issue. It doesn't need to
> >> be externally visible, but that's not all of its problems - it's also shared
> >> between processes so there's an ABI contract between primary and secondary
> >> too. This means that, even if the structure itself is not public, any
> >> changes to it will still result in an ABI break. That's the nature of our
> >> shared memory.
> >>
> >> In other words, if your goal is to avoid ABI breaks on changing this
> >> structure, making it internal won't help in the slightest.
> >>
> >
> > Is there an ABI contract between primary and secondary. I always assumed
> > that if using secondary processes the requirement (though undocumented) was
> > that both had to be linked against the exact same versions of DPDK?
> >
>
> The fact that it's undocumented means we can't assume everyone will do
> that :)
>
> If the community agrees that primary/secondary processes should always
> use the same DPDK version (regardless of static/dynamic builds etc.),
> then this problem would probably be solved.
+1 to document that primary/secondary with different DPDK versions
is not supported.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:38 0% ` Thomas Monjalon
@ 2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 10:08 0% ` Burakov, Anatoly
1 sibling, 2 replies; 200+ results
From: Ray Kinsella @ 2019-05-09 9:50 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
On 09/05/2019 10:38, Thomas Monjalon wrote:
> 09/05/2019 11:37, Burakov, Anatoly:
>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>
>>>>> On Wed, 8 May 2019 17:48:06 -0500
>>>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>
>>>>> > Due to an upcoming fix to allow the timer library to safely free its
>>>>> > allocations during the finalize() call[1], an ABI change will be
>>>>> > required. A new lock will be added to the rte_mem_config structure,
>>>>> > which will be used by the timer library to synchronize init/finalize
>>>>> > calls among multiple processes.
>>>>> >
>>>>> > [1] http://patches.dpdk.org/patch/53334/
>>>>> >
>>>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>> >
>>>>> > + ``rte_eal_devargs_type_count``
>>>>> >
>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>> new lock that
>>>>> > + will allow the timer subsystem to safely release its
>>>>> allocations at cleanup
>>>>> > + time. This will result in an ABI break.
>>>>> > +
>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>>>> ``rte_vfio_dma_unmap`` APIs which
>>>>> > have been replaced with ``rte_dev_dma_map`` and
>>>>> ``rte_dev_dma_unmap``
>>>>> > functions. The due date for the removal targets DPDK 20.02.
>>>>>
>>>>> NAK
>>>>>
>>>>> Please go to the effort of making rte_mem_config not part of the
>>>>> visible ABI.
>>>>> Then change it.
>>>>>
>>>>>
>>>>> +1.
>>>>
>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>> be externally visible, but that's not all of its problems - it's also shared
>>>> between processes so there's an ABI contract between primary and secondary
>>>> too. This means that, even if the structure itself is not public, any
>>>> changes to it will still result in an ABI break. That's the nature of our
>>>> shared memory.
>>>>
>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>> structure, making it internal won't help in the slightest.
>>>>
>>>
>>> Is there an ABI contract between primary and secondary. I always assumed
>>> that if using secondary processes the requirement (though undocumented) was
>>> that both had to be linked against the exact same versions of DPDK?
>>>
>>
>> The fact that it's undocumented means we can't assume everyone will do
>> that :)
>>
>> If the community agrees that primary/secondary processes should always
>> use the same DPDK version (regardless of static/dynamic builds etc.),
>> then this problem would probably be solved.
>
> +1 to document that primary/secondary with different DPDK versions
> is not supported.
>
+1,
but I think we need to go farther - we need a secondary process to check
with the primary process.
We can't assume everyone will read the documentation.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:50 0% ` Ray Kinsella
@ 2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 10:08 0% ` Burakov, Anatoly
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-05-09 9:50 UTC (permalink / raw)
To: Thomas Monjalon, Burakov, Anatoly
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
On 09/05/2019 10:38, Thomas Monjalon wrote:
> 09/05/2019 11:37, Burakov, Anatoly:
>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>
>>>>> On Wed, 8 May 2019 17:48:06 -0500
>>>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>
>>>>> > Due to an upcoming fix to allow the timer library to safely free its
>>>>> > allocations during the finalize() call[1], an ABI change will be
>>>>> > required. A new lock will be added to the rte_mem_config structure,
>>>>> > which will be used by the timer library to synchronize init/finalize
>>>>> > calls among multiple processes.
>>>>> >
>>>>> > [1] http://patches.dpdk.org/patch/53334/
>>>>> >
>>>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>> >
>>>>> > + ``rte_eal_devargs_type_count``
>>>>> >
>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>> new lock that
>>>>> > + will allow the timer subsystem to safely release its
>>>>> allocations at cleanup
>>>>> > + time. This will result in an ABI break.
>>>>> > +
>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>>>> ``rte_vfio_dma_unmap`` APIs which
>>>>> > have been replaced with ``rte_dev_dma_map`` and
>>>>> ``rte_dev_dma_unmap``
>>>>> > functions. The due date for the removal targets DPDK 20.02.
>>>>>
>>>>> NAK
>>>>>
>>>>> Please go to the effort of making rte_mem_config not part of the
>>>>> visible ABI.
>>>>> Then change it.
>>>>>
>>>>>
>>>>> +1.
>>>>
>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>> be externally visible, but that's not all of its problems - it's also shared
>>>> between processes so there's an ABI contract between primary and secondary
>>>> too. This means that, even if the structure itself is not public, any
>>>> changes to it will still result in an ABI break. That's the nature of our
>>>> shared memory.
>>>>
>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>> structure, making it internal won't help in the slightest.
>>>>
>>>
>>> Is there an ABI contract between primary and secondary. I always assumed
>>> that if using secondary processes the requirement (though undocumented) was
>>> that both had to be linked against the exact same versions of DPDK?
>>>
>>
>> The fact that it's undocumented means we can't assume everyone will do
>> that :)
>>
>> If the community agrees that primary/secondary processes should always
>> use the same DPDK version (regardless of static/dynamic builds etc.),
>> then this problem would probably be solved.
>
> +1 to document that primary/secondary with different DPDK versions
> is not supported.
>
+1,
but I think we need to go farther - we need a secondary process to check
with the primary process.
We can't assume everyone will read the documentation.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 9:50 0% ` Ray Kinsella
@ 2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-10 14:42 0% ` Stephen Hemminger
1 sibling, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 10:08 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
On 09-May-19 10:50 AM, Ray Kinsella wrote:
>
>
> On 09/05/2019 10:38, Thomas Monjalon wrote:
>> 09/05/2019 11:37, Burakov, Anatoly:
>>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>>
>>>>>> On Wed, 8 May 2019 17:48:06 -0500
>>>>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>>
>>>>>> > Due to an upcoming fix to allow the timer library to safely free its
>>>>>> > allocations during the finalize() call[1], an ABI change will be
>>>>>> > required. A new lock will be added to the rte_mem_config structure,
>>>>>> > which will be used by the timer library to synchronize init/finalize
>>>>>> > calls among multiple processes.
>>>>>> >
>>>>>> > [1] http://patches.dpdk.org/patch/53334/
>>>>>> >
>>>>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>>>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>> >
>>>>>> > + ``rte_eal_devargs_type_count``
>>>>>> >
>>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>> new lock that
>>>>>> > + will allow the timer subsystem to safely release its
>>>>>> allocations at cleanup
>>>>>> > + time. This will result in an ABI break.
>>>>>> > +
>>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>>>>> ``rte_vfio_dma_unmap`` APIs which
>>>>>> > have been replaced with ``rte_dev_dma_map`` and
>>>>>> ``rte_dev_dma_unmap``
>>>>>> > functions. The due date for the removal targets DPDK 20.02.
>>>>>>
>>>>>> NAK
>>>>>>
>>>>>> Please go to the effort of making rte_mem_config not part of the
>>>>>> visible ABI.
>>>>>> Then change it.
>>>>>>
>>>>>>
>>>>>> +1.
>>>>>
>>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>>> be externally visible, but that's not all of its problems - it's also shared
>>>>> between processes so there's an ABI contract between primary and secondary
>>>>> too. This means that, even if the structure itself is not public, any
>>>>> changes to it will still result in an ABI break. That's the nature of our
>>>>> shared memory.
>>>>>
>>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>>> structure, making it internal won't help in the slightest.
>>>>>
>>>>
>>>> Is there an ABI contract between primary and secondary. I always assumed
>>>> that if using secondary processes the requirement (though undocumented) was
>>>> that both had to be linked against the exact same versions of DPDK?
>>>>
>>>
>>> The fact that it's undocumented means we can't assume everyone will do
>>> that :)
>>>
>>> If the community agrees that primary/secondary processes should always
>>> use the same DPDK version (regardless of static/dynamic builds etc.),
>>> then this problem would probably be solved.
>>
>> +1 to document that primary/secondary with different DPDK versions
>> is not supported.
>>
>
> +1,
>
> but I think we need to go farther - we need a secondary process to check
> with the primary process.
> We can't assume everyone will read the documentation.
>
That easily can be done, yes.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 10:08 0% ` Burakov, Anatoly
@ 2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-10 14:42 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 10:08 UTC (permalink / raw)
To: Ray Kinsella, Thomas Monjalon
Cc: Bruce Richardson, David Marchand, Stephen Hemminger,
Erik Gabriel Carrillo, dev
On 09-May-19 10:50 AM, Ray Kinsella wrote:
>
>
> On 09/05/2019 10:38, Thomas Monjalon wrote:
>> 09/05/2019 11:37, Burakov, Anatoly:
>>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
>>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
>>>>> On 09-May-19 8:05 AM, David Marchand wrote:
>>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
>>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
>>>>>>
>>>>>> On Wed, 8 May 2019 17:48:06 -0500
>>>>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>> <mailto:erik.g.carrillo@intel.com>> wrote:
>>>>>>
>>>>>> > Due to an upcoming fix to allow the timer library to safely free its
>>>>>> > allocations during the finalize() call[1], an ABI change will be
>>>>>> > required. A new lock will be added to the rte_mem_config structure,
>>>>>> > which will be used by the timer library to synchronize init/finalize
>>>>>> > calls among multiple processes.
>>>>>> >
>>>>>> > [1] http://patches.dpdk.org/patch/53334/
>>>>>> >
>>>>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
>>>>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
>>>>>> > --- a/doc/guides/rel_notes/deprecation.rst
>>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst
>>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices
>>>>>> >
>>>>>> > + ``rte_eal_devargs_type_count``
>>>>>> >
>>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a
>>>>>> new lock that
>>>>>> > + will allow the timer subsystem to safely release its
>>>>>> allocations at cleanup
>>>>>> > + time. This will result in an ABI break.
>>>>>> > +
>>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and
>>>>>> ``rte_vfio_dma_unmap`` APIs which
>>>>>> > have been replaced with ``rte_dev_dma_map`` and
>>>>>> ``rte_dev_dma_unmap``
>>>>>> > functions. The due date for the removal targets DPDK 20.02.
>>>>>>
>>>>>> NAK
>>>>>>
>>>>>> Please go to the effort of making rte_mem_config not part of the
>>>>>> visible ABI.
>>>>>> Then change it.
>>>>>>
>>>>>>
>>>>>> +1.
>>>>>
>>>>> I agree on principle, however this won't solve the issue. It doesn't need to
>>>>> be externally visible, but that's not all of its problems - it's also shared
>>>>> between processes so there's an ABI contract between primary and secondary
>>>>> too. This means that, even if the structure itself is not public, any
>>>>> changes to it will still result in an ABI break. That's the nature of our
>>>>> shared memory.
>>>>>
>>>>> In other words, if your goal is to avoid ABI breaks on changing this
>>>>> structure, making it internal won't help in the slightest.
>>>>>
>>>>
>>>> Is there an ABI contract between primary and secondary. I always assumed
>>>> that if using secondary processes the requirement (though undocumented) was
>>>> that both had to be linked against the exact same versions of DPDK?
>>>>
>>>
>>> The fact that it's undocumented means we can't assume everyone will do
>>> that :)
>>>
>>> If the community agrees that primary/secondary processes should always
>>> use the same DPDK version (regardless of static/dynamic builds etc.),
>>> then this problem would probably be solved.
>>
>> +1 to document that primary/secondary with different DPDK versions
>> is not supported.
>>
>
> +1,
>
> but I think we need to go farther - we need a secondary process to check
> with the primary process.
> We can't assume everyone will read the documentation.
>
That easily can be done, yes.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-08 22:48 8% [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup Erik Gabriel Carrillo
2019-05-08 22:48 8% ` Erik Gabriel Carrillo
2019-05-09 1:11 3% ` Stephen Hemminger
@ 2019-05-09 11:53 0% ` Burakov, Anatoly
2019-05-09 11:53 0% ` Burakov, Anatoly
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
3 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-05-09 11:53 UTC (permalink / raw)
To: Erik Gabriel Carrillo, thomas; +Cc: dev
On 08-May-19 11:48 PM, Erik Gabriel Carrillo wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
>
> [1] http://patches.dpdk.org/patch/53334/
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
As per discussion, please change the deprecation notice to instead make
rte_eal_memconfig private.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 11:53 0% ` Burakov, Anatoly
@ 2019-05-09 11:53 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-09 11:53 UTC (permalink / raw)
To: Erik Gabriel Carrillo, thomas; +Cc: dev
On 08-May-19 11:48 PM, Erik Gabriel Carrillo wrote:
> Due to an upcoming fix to allow the timer library to safely free its
> allocations during the finalize() call[1], an ABI change will be
> required. A new lock will be added to the rte_mem_config structure,
> which will be used by the timer library to synchronize init/finalize
> calls among multiple processes.
>
> [1] http://patches.dpdk.org/patch/53334/
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
As per discussion, please change the deprecation notice to instead make
rte_eal_memconfig private.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-08 22:48 8% [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup Erik Gabriel Carrillo
` (2 preceding siblings ...)
2019-05-09 11:53 0% ` Burakov, Anatoly
@ 2019-05-09 18:51 9% ` Erik Gabriel Carrillo
2019-05-09 18:51 9% ` Erik Gabriel Carrillo
` (2 more replies)
3 siblings, 3 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-09 18:51 UTC (permalink / raw)
To: thomas
Cc: stephen, david.marchand, anatoly.burakov, bruce.richardson, mdr, dev
It is planned to make the rte_mem_config struct of the EAL private to
remove it from the visible ABI. Add a notice to announce the intention.
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
changes in v2:
- Original deprecation notice announced a change to the rte_mem_config
struct that would break ABI. Update the notice to instead announce
the struct will be made private. (Stephen, Anatoly, David)
doc/guides/rel_notes/deprecation.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..a7dff6b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,9 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: the ``rte_mem_config`` struct will be made private to remove it from the
+ externally visible ABI and allow it to be updated in the future.
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
--
2.6.4
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
@ 2019-05-09 18:51 9% ` Erik Gabriel Carrillo
2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 13:44 0% ` David Marchand
2 siblings, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-05-09 18:51 UTC (permalink / raw)
To: thomas
Cc: stephen, david.marchand, anatoly.burakov, bruce.richardson, mdr, dev
It is planned to make the rte_mem_config struct of the EAL private to
remove it from the visible ABI. Add a notice to announce the intention.
Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
---
changes in v2:
- Original deprecation notice announced a change to the rte_mem_config
struct that would break ABI. Update the notice to instead announce
the struct will be made private. (Stephen, Anatoly, David)
doc/guides/rel_notes/deprecation.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b47c8c2..a7dff6b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -31,6 +31,9 @@ Deprecation Notices
+ ``rte_eal_devargs_type_count``
+* eal: the ``rte_mem_config`` struct will be made private to remove it from the
+ externally visible ABI and allow it to be updated in the future.
+
* vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
functions. The due date for the removal targets DPDK 20.02.
--
2.6.4
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [dpdk-stable] [PATCH 4/4] devtools: fix direct additions to stable API
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2019-05-03 14:34 3% ` David Marchand
@ 2019-05-09 21:40 0% ` Thomas Monjalon
2019-05-09 21:40 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-05-09 21:40 UTC (permalink / raw)
To: David Marchand; +Cc: stable, dev, nhorman
03/05/2019 16:34, David Marchand:
> The incriminated commit broke the detection of new symbols skipping the
> EXPERIMENTAL step before entering a stable abi section.
> sed won't return an error, check a null output instead.
>
> Fixes: 3630757803ab ("devtools: accept experimental symbol promotion")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Series applied (without patch 2), thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-stable] [PATCH 4/4] devtools: fix direct additions to stable API
2019-05-09 21:40 0% ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
@ 2019-05-09 21:40 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-05-09 21:40 UTC (permalink / raw)
To: David Marchand; +Cc: stable, dev, nhorman
03/05/2019 16:34, David Marchand:
> The incriminated commit broke the detection of new symbols skipping the
> EXPERIMENTAL step before entering a stable abi section.
> sed won't return an error, check a null output instead.
>
> Fixes: 3630757803ab ("devtools: accept experimental symbol promotion")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Series applied (without patch 2), thanks
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK Windows Community call - 02 May 2019
@ 2019-05-09 23:34 3% Ranjit Menon
2019-05-09 23:34 3% ` Ranjit Menon
0 siblings, 1 reply; 200+ results
From: Ranjit Menon @ 2019-05-09 23:34 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Anand (anand.rawat@intel.com)
Harini (harini.ramakrishnan@microsoft.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
Haseeb (Haseeb.Gani@cavium.com)
(shshaikh@marvell.com)
Naresh (nareshkumar.pbs@broadcom.com)
Contact Cathal to be added to this meeting invite.
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org Windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives
c. Any other business
Minutes:
-------
- Intel trying to integrate Windows compilation into CI.
- Working with Qian's team for this.
- Issue is Linux CI builds still use make - Windows is using meson.
- This will require some alignment.
- Will work next with validation team to include Windows testing
- possibly in time for 19.08
- Also need to bring Windows into community lab for unit testing
- use Bugzilla to log request to lab to increase scope for Windows
- Draft repo needs a new branch to host latest Windows development
- currently WIP
- What about rte_panic() removal from Windows EAL?
- Deprecation notice to be sent for 19.05 in case of change to API/ABI
- Windows will update based on common API change.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] DPDK Windows Community call - 02 May 2019
2019-05-09 23:34 3% [dpdk-dev] DPDK Windows Community call - 02 May 2019 Ranjit Menon
@ 2019-05-09 23:34 3% ` Ranjit Menon
0 siblings, 0 replies; 200+ results
From: Ranjit Menon @ 2019-05-09 23:34 UTC (permalink / raw)
To: dev
Attendees:
(Present)
Thomas (thomas@monjalon.net)
Bruce (bruce.richardson@intel.com)
Cathal (cathal.ohare@intel.com)
Pallavi (pallavi.kadam@intel.com)
Ranjit (ranjit.menon@intel.com)
Anand (anand.rawat@intel.com)
Harini (harini.ramakrishnan@microsoft.com)
Eilon (eilong@mellanox.com)
Raslan (rasland@mellanox.com)
(yohadt@mellanox.com)
Jeffrey (jeffrey.tippet@microsoft.com)
Omar (ocardona@microsoft.com)
Khoa (khot@microsoft.com)
Haseeb (Haseeb.Gani@cavium.com)
(shshaikh@marvell.com)
Naresh (nareshkumar.pbs@broadcom.com)
Contact Cathal to be added to this meeting invite.
Agenda:
------
Meeting for 1 hour as a place holder every 2 weeks.
Expect call to last 30-40 minutes or longer as needed.
Encourage other dpdk.org Windows partners to join this call.
Minutes via public mailing list.
a. Current release
b. Improvements/Shared objectives
c. Any other business
Minutes:
-------
- Intel trying to integrate Windows compilation into CI.
- Working with Qian's team for this.
- Issue is Linux CI builds still use make - Windows is using meson.
- This will require some alignment.
- Will work next with validation team to include Windows testing
- possibly in time for 19.08
- Also need to bring Windows into community lab for unit testing
- use Bugzilla to log request to lab to increase scope for Windows
- Draft repo needs a new branch to host latest Windows development
- currently WIP
- What about rte_panic() removal from Windows EAL?
- Deprecation notice to be sent for 19.05 in case of change to API/ABI
- Windows will update based on common API change.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
2019-05-09 18:51 9% ` Erik Gabriel Carrillo
@ 2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:34 0% ` Bruce Richardson
2019-05-10 13:44 0% ` David Marchand
2 siblings, 2 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-10 9:31 UTC (permalink / raw)
To: Erik Gabriel Carrillo, thomas
Cc: stephen, david.marchand, bruce.richardson, mdr, dev
On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:
> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI. Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v2:
> - Original deprecation notice announced a change to the rte_mem_config
> struct that would break ABI. Update the notice to instead announce
> the struct will be made private. (Stephen, Anatoly, David)
>
> doc/guides/rel_notes/deprecation.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it from the
> + externally visible ABI and allow it to be updated in the future.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-10 9:31 0% ` Burakov, Anatoly
@ 2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:34 0% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-05-10 9:31 UTC (permalink / raw)
To: Erik Gabriel Carrillo, thomas
Cc: stephen, david.marchand, bruce.richardson, mdr, dev
On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:
> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI. Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v2:
> - Original deprecation notice announced a change to the rte_mem_config
> struct that would break ABI. Update the notice to instead announce
> the struct will be made private. (Stephen, Anatoly, David)
>
> doc/guides/rel_notes/deprecation.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it from the
> + externally visible ABI and allow it to be updated in the future.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API
@ 2019-05-10 9:33 3% ` Bruce Richardson
2019-05-10 9:33 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-05-10 9:33 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Hunt, David, Hajkowski, john.mcnamara, marko.kovacevic
On Fri, May 10, 2019 at 10:28:14AM +0100, Bruce Richardson wrote:
> On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote:
> > > > From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
> > > >
> > > > Function rte_power_set_env will no longer return
> > > > success on attempt to set env in initialized state.
> > > >
> > > > Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
> > >
> > > Acked-by: David Hunt <david.hunt@intel.com>
> >
> > Any other comment about this deprecation notice?
> >
> Seems ok to me, though the actual text is maybe a little unclear. It
> implies that the function will always return -1 unless the variable is
> unset when the function terminates (which seems to imply a failure case).
> What I presume is meant is that we have three possibilities:
>
> * The variable is set by the function -> return 0
> * The varaible is already set, so no action needed -> return -1 (and set
> rte_errno to EEXIST or EALREADY??)
> * Setting the variable failed -> return -1 (and set rte_errno to ??)
>
> Is my understanding correct? Can the deprecation notice be improved to make
> it clear that only the middle case is the one being changed, e.g. by adding
> "in this case" to the second sentence. It might also be worthwhile calling
> out what the errno value will be to identify this failure vs regular
> failures.
>
> /Bruce
>
> PS: For this case, is there a reason to make it an error? Would a +1 value
> not also do, so anything non-zero implies no work done, and anything >=0
> means that the value is set? Call set on something already set doesn't
> really seem like an error case to me.
Sorry, forgot to put:
For changing the ABI itself, no issues, so with the small rewording asked
for, please add my ack.
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/1] doc: announce change in power API
2019-05-10 9:33 3% ` Bruce Richardson
@ 2019-05-10 9:33 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-05-10 9:33 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Hunt, David, Hajkowski, john.mcnamara, marko.kovacevic
On Fri, May 10, 2019 at 10:28:14AM +0100, Bruce Richardson wrote:
> On Fri, May 10, 2019 at 01:28:09AM +0200, Thomas Monjalon wrote:
> > > > From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
> > > >
> > > > Function rte_power_set_env will no longer return
> > > > success on attempt to set env in initialized state.
> > > >
> > > > Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
> > >
> > > Acked-by: David Hunt <david.hunt@intel.com>
> >
> > Any other comment about this deprecation notice?
> >
> Seems ok to me, though the actual text is maybe a little unclear. It
> implies that the function will always return -1 unless the variable is
> unset when the function terminates (which seems to imply a failure case).
> What I presume is meant is that we have three possibilities:
>
> * The variable is set by the function -> return 0
> * The varaible is already set, so no action needed -> return -1 (and set
> rte_errno to EEXIST or EALREADY??)
> * Setting the variable failed -> return -1 (and set rte_errno to ??)
>
> Is my understanding correct? Can the deprecation notice be improved to make
> it clear that only the middle case is the one being changed, e.g. by adding
> "in this case" to the second sentence. It might also be worthwhile calling
> out what the errno value will be to identify this failure vs regular
> failures.
>
> /Bruce
>
> PS: For this case, is there a reason to make it an error? Would a +1 value
> not also do, so anything non-zero implies no work done, and anything >=0
> means that the value is set? Call set on something already set doesn't
> really seem like an error case to me.
Sorry, forgot to put:
For changing the ABI itself, no issues, so with the small rewording asked
for, please add my ack.
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:31 0% ` Burakov, Anatoly
@ 2019-05-10 9:34 0% ` Bruce Richardson
2019-05-10 9:34 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-05-10 9:34 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Erik Gabriel Carrillo, thomas, stephen, david.marchand, mdr, dev
On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:
> > It is planned to make the rte_mem_config struct of the EAL private to
> > remove it from the visible ABI. Add a notice to announce the intention.
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> > ---
> > changes in v2:
> > - Original deprecation notice announced a change to the rte_mem_config
> > struct that would break ABI. Update the notice to instead announce
> > the struct will be made private. (Stephen, Anatoly, David)
> >
> > doc/guides/rel_notes/deprecation.rst | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index b47c8c2..a7dff6b 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,9 @@ Deprecation Notices
> > + ``rte_eal_devargs_type_count``
> > +* eal: the ``rte_mem_config`` struct will be made private to remove it from the
> > + externally visible ABI and allow it to be updated in the future.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
> >
>
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-10 9:34 0% ` Bruce Richardson
@ 2019-05-10 9:34 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-05-10 9:34 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Erik Gabriel Carrillo, thomas, stephen, david.marchand, mdr, dev
On Fri, May 10, 2019 at 10:31:21AM +0100, Burakov, Anatoly wrote:
> On 09-May-19 7:51 PM, Erik Gabriel Carrillo wrote:
> > It is planned to make the rte_mem_config struct of the EAL private to
> > remove it from the visible ABI. Add a notice to announce the intention.
> >
> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> > ---
> > changes in v2:
> > - Original deprecation notice announced a change to the rte_mem_config
> > struct that would break ABI. Update the notice to instead announce
> > the struct will be made private. (Stephen, Anatoly, David)
> >
> > doc/guides/rel_notes/deprecation.rst | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index b47c8c2..a7dff6b 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -31,6 +31,9 @@ Deprecation Notices
> > + ``rte_eal_devargs_type_count``
> > +* eal: the ``rte_mem_config`` struct will be made private to remove it from the
> > + externally visible ABI and allow it to be updated in the future.
> > +
> > * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs which
> > have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> > functions. The due date for the removal targets DPDK 20.02.
> >
>
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] Discussion on the OS Packaging of DPDK
@ 2019-05-10 13:01 4% Ray Kinsella
2019-05-10 13:01 4% ` Ray Kinsella
2019-05-10 13:43 0% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Ray Kinsella @ 2019-05-10 13:01 UTC (permalink / raw)
To: techboard, Billy McFall, Thomas F Herbert
Cc: dpdk-dev, Luca Boccassi, ndas, Christian Ehrhardt, Stokes, Ian
( from the undersigned )
Hi folks,
In light of the renewed community discussion on API Stability
(https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
right time to open a discussion on how DPDK is distributed and updated.
To this point in time, DPDK's primary distribution method has been as
source code distributed as a tarball from dpdk.org. This distribution
method, in addition to abi instability and the dpdk's build system
default behaviour of static linking have all encouraged the "tight
coupling" or "vendorization" of DPDK.
These behaviours makes it a challenge for end users, those deploying
applications based on DPDK, to manage and update DPDK in a method
consistent with other system libraries. For instance, an end user may
not have any idea which version of DPDK a consuming application may be
using and if this DPDK version is reasonably up to date with the latest
upstream version. This would not be the case for other system libraries
such as glibc.
For these reasons, now is the right time for DPDK to embrace standard
Operating System practices for distributing and updating system
libraries. The current industry push towards cloud and
cloud-friendliness make addressing this issue all the more timely.
To this end, the following proposals are made for discussion at the next
techboard meeting:-
* The primary method of distributing DPDK should be as an operating
system package, dpdk.org should be updated to reflect this reality and
provide OS installation details in place of tarball downloads.
* DPDK should build as a dynamic shared libraries by default, to
encourage loose coupling with consuming applications.
* Future guarantees around ABI/API stability should be provided, so that
OS packagers can offer safe upgrade paths for consuming applications.
Look forward to the discussion, thank you,
Luca Boccassi, Debian maintainer and DPDK LTS maintainer
Nirmoy Das, SUSE dpdk maintainer
Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
Ian Stokes, Open vSwitch maintainer
Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
Billy McFall, DPDK consumer and FD.io/VPP Contributor
Ray Kinsella, DPDK and FD.io Contributor
^ permalink raw reply [relevance 4%]
* [dpdk-dev] Discussion on the OS Packaging of DPDK
2019-05-10 13:01 4% [dpdk-dev] Discussion on the OS Packaging of DPDK Ray Kinsella
@ 2019-05-10 13:01 4% ` Ray Kinsella
2019-05-10 13:43 0% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Ray Kinsella @ 2019-05-10 13:01 UTC (permalink / raw)
To: techboard, Billy McFall, Thomas F Herbert
Cc: dpdk-dev, Luca Boccassi, ndas, Christian Ehrhardt, Stokes, Ian
( from the undersigned )
Hi folks,
In light of the renewed community discussion on API Stability
(https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
right time to open a discussion on how DPDK is distributed and updated.
To this point in time, DPDK's primary distribution method has been as
source code distributed as a tarball from dpdk.org. This distribution
method, in addition to abi instability and the dpdk's build system
default behaviour of static linking have all encouraged the "tight
coupling" or "vendorization" of DPDK.
These behaviours makes it a challenge for end users, those deploying
applications based on DPDK, to manage and update DPDK in a method
consistent with other system libraries. For instance, an end user may
not have any idea which version of DPDK a consuming application may be
using and if this DPDK version is reasonably up to date with the latest
upstream version. This would not be the case for other system libraries
such as glibc.
For these reasons, now is the right time for DPDK to embrace standard
Operating System practices for distributing and updating system
libraries. The current industry push towards cloud and
cloud-friendliness make addressing this issue all the more timely.
To this end, the following proposals are made for discussion at the next
techboard meeting:-
* The primary method of distributing DPDK should be as an operating
system package, dpdk.org should be updated to reflect this reality and
provide OS installation details in place of tarball downloads.
* DPDK should build as a dynamic shared libraries by default, to
encourage loose coupling with consuming applications.
* Future guarantees around ABI/API stability should be provided, so that
OS packagers can offer safe upgrade paths for consuming applications.
Look forward to the discussion, thank you,
Luca Boccassi, Debian maintainer and DPDK LTS maintainer
Nirmoy Das, SUSE dpdk maintainer
Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
Ian Stokes, Open vSwitch maintainer
Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
Billy McFall, DPDK consumer and FD.io/VPP Contributor
Ray Kinsella, DPDK and FD.io Contributor
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK
2019-05-10 13:01 4% [dpdk-dev] Discussion on the OS Packaging of DPDK Ray Kinsella
2019-05-10 13:01 4% ` Ray Kinsella
@ 2019-05-10 13:43 0% ` Bruce Richardson
2019-05-10 13:43 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-05-10 13:43 UTC (permalink / raw)
To: Ray Kinsella
Cc: techboard, Billy McFall, Thomas F Herbert, dpdk-dev,
Luca Boccassi, ndas, Christian Ehrhardt, Stokes, Ian
On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> ( from the undersigned )
>
> Hi folks,
>
> In light of the renewed community discussion on API Stability
> (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> right time to open a discussion on how DPDK is distributed and updated.
>
> To this point in time, DPDK's primary distribution method has been as
> source code distributed as a tarball from dpdk.org. This distribution
> method, in addition to abi instability and the dpdk's build system
> default behaviour of static linking have all encouraged the "tight
> coupling" or "vendorization" of DPDK.
>
> These behaviours makes it a challenge for end users, those deploying
> applications based on DPDK, to manage and update DPDK in a method
> consistent with other system libraries. For instance, an end user may
> not have any idea which version of DPDK a consuming application may be
> using and if this DPDK version is reasonably up to date with the latest
> upstream version. This would not be the case for other system libraries
> such as glibc.
>
> For these reasons, now is the right time for DPDK to embrace standard
> Operating System practices for distributing and updating system
> libraries. The current industry push towards cloud and
> cloud-friendliness make addressing this issue all the more timely.
>
> To this end, the following proposals are made for discussion at the next
> techboard meeting:-
>
> * The primary method of distributing DPDK should be as an operating
> system package, dpdk.org should be updated to reflect this reality and
> provide OS installation details in place of tarball downloads.
I really like that idea. Since DPDK is available in distro packages that
should be the first port of call for users getting DPDK. Since it's just a
doc update - as I understand it anyway - it should be easy to implement if
agreed, which is a nice bonus.
>
> * DPDK should build as a dynamic shared libraries by default, to
> encourage loose coupling with consuming applications.
>
To a certain extent, this only applies with the "make" build system, which
is due to be deprecated in the next release and removed sometime next year.
With builds done with meson and ninja, both shared and static libraries are
always built. The default setting though remains as "static" which applies
only to the linking of applications as part of the DPDK build. This default
was set mainly for legacy purposes, but also has benefits for us developers
working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
and EAL_PMD_PATH values for running applications we've built. Therefore,
I'm not sure of the value of changing the default here - it's certainly
less important than the default in the "make" build system where only one
library type at a time was built.
> * Future guarantees around ABI/API stability should be provided, so that
> OS packagers can offer safe upgrade paths for consuming applications.
>
> Look forward to the discussion, thank you,
>
> Luca Boccassi, Debian maintainer and DPDK LTS maintainer
> Nirmoy Das, SUSE dpdk maintainer
> Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
> Ian Stokes, Open vSwitch maintainer
> Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
> Billy McFall, DPDK consumer and FD.io/VPP Contributor
> Ray Kinsella, DPDK and FD.io Contributor
Thanks all for kicking off this discussion.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK
2019-05-10 13:43 0% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
@ 2019-05-10 13:43 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-05-10 13:43 UTC (permalink / raw)
To: Ray Kinsella
Cc: techboard, Billy McFall, Thomas F Herbert, dpdk-dev,
Luca Boccassi, ndas, Christian Ehrhardt, Stokes, Ian
On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> ( from the undersigned )
>
> Hi folks,
>
> In light of the renewed community discussion on API Stability
> (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> right time to open a discussion on how DPDK is distributed and updated.
>
> To this point in time, DPDK's primary distribution method has been as
> source code distributed as a tarball from dpdk.org. This distribution
> method, in addition to abi instability and the dpdk's build system
> default behaviour of static linking have all encouraged the "tight
> coupling" or "vendorization" of DPDK.
>
> These behaviours makes it a challenge for end users, those deploying
> applications based on DPDK, to manage and update DPDK in a method
> consistent with other system libraries. For instance, an end user may
> not have any idea which version of DPDK a consuming application may be
> using and if this DPDK version is reasonably up to date with the latest
> upstream version. This would not be the case for other system libraries
> such as glibc.
>
> For these reasons, now is the right time for DPDK to embrace standard
> Operating System practices for distributing and updating system
> libraries. The current industry push towards cloud and
> cloud-friendliness make addressing this issue all the more timely.
>
> To this end, the following proposals are made for discussion at the next
> techboard meeting:-
>
> * The primary method of distributing DPDK should be as an operating
> system package, dpdk.org should be updated to reflect this reality and
> provide OS installation details in place of tarball downloads.
I really like that idea. Since DPDK is available in distro packages that
should be the first port of call for users getting DPDK. Since it's just a
doc update - as I understand it anyway - it should be easy to implement if
agreed, which is a nice bonus.
>
> * DPDK should build as a dynamic shared libraries by default, to
> encourage loose coupling with consuming applications.
>
To a certain extent, this only applies with the "make" build system, which
is due to be deprecated in the next release and removed sometime next year.
With builds done with meson and ninja, both shared and static libraries are
always built. The default setting though remains as "static" which applies
only to the linking of applications as part of the DPDK build. This default
was set mainly for legacy purposes, but also has benefits for us developers
working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
and EAL_PMD_PATH values for running applications we've built. Therefore,
I'm not sure of the value of changing the default here - it's certainly
less important than the default in the "make" build system where only one
library type at a time was built.
> * Future guarantees around ABI/API stability should be provided, so that
> OS packagers can offer safe upgrade paths for consuming applications.
>
> Look forward to the discussion, thank you,
>
> Luca Boccassi, Debian maintainer and DPDK LTS maintainer
> Nirmoy Das, SUSE dpdk maintainer
> Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
> Ian Stokes, Open vSwitch maintainer
> Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
> Billy McFall, DPDK consumer and FD.io/VPP Contributor
> Ray Kinsella, DPDK and FD.io Contributor
Thanks all for kicking off this discussion.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
2019-05-09 18:51 9% ` Erik Gabriel Carrillo
2019-05-10 9:31 0% ` Burakov, Anatoly
@ 2019-05-10 13:44 0% ` David Marchand
2019-05-10 13:44 0% ` David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-05-10 13:44 UTC (permalink / raw)
To: Erik Gabriel Carrillo
Cc: Thomas Monjalon, Stephen Hemminger, Burakov, Anatoly,
Bruce Richardson, Ray Kinsella, dev, mw, mk, gtzalik, evgenys
On Thu, May 9, 2019 at 8:53 PM Erik Gabriel Carrillo <
erik.g.carrillo@intel.com> wrote:
> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI. Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v2:
> - Original deprecation notice announced a change to the rte_mem_config
> struct that would break ABI. Update the notice to instead announce
> the struct will be made private. (Stephen, Anatoly, David)
>
> doc/guides/rel_notes/deprecation.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it
> from the
> + externally visible ABI and allow it to be updated in the future.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
> --
> 2.6.4
>
>
I had a look at the current callers, trying to see what "hiding" means.
$ git grep -Elw '(rte_mem_config|mem_config)' origin/master --
origin/master:app/test/test_memzone.c
origin/master:doc/guides/rel_notes/release_18_11.rst
origin/master:drivers/bus/fslmc/fslmc_vfio.c
origin/master:drivers/net/ena/ena_ethdev.c
origin/master:drivers/net/mlx4/mlx4_mr.c
origin/master:drivers/net/mlx5/mlx5_mr.c
origin/master:drivers/net/virtio/virtio_user/virtio_user_dev.c
origin/master:lib/librte_eal/common/eal_common_memory.c
origin/master:lib/librte_eal/common/eal_common_memzone.c
origin/master:lib/librte_eal/common/eal_common_tailqs.c
origin/master:lib/librte_eal/common/include/rte_eal.h
origin/master:lib/librte_eal/common/include/rte_eal_memconfig.h
origin/master:lib/librte_eal/common/malloc_heap.c
origin/master:lib/librte_eal/common/rte_malloc.c
origin/master:lib/librte_eal/freebsd/eal/eal.c
origin/master:lib/librte_eal/freebsd/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal.c
origin/master:lib/librte_eal/linux/eal/eal_memalloc.c
origin/master:lib/librte_eal/linux/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal_vfio.c
- I understand that the following drivers will need a new lock/unlock api
to protect calls to the memory api.
drivers/bus/fslmc/fslmc_vfio.c
drivers/net/mlx4/mlx4_mr.c
drivers/net/mlx5/mlx5_mr.c
drivers/net/virtio/virtio_user/virtio_user_dev.c
- I have a little trouble with this one, so there might be a new api for
this driver usecase.
A discussion will have to happen with its maintainers (added in CC:).
drivers/net/ena/ena_ethdev.c
Apart from this, I am ok with the objective, which is to hide one more eal
internal structure.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config
2019-05-10 13:44 0% ` David Marchand
@ 2019-05-10 13:44 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-05-10 13:44 UTC (permalink / raw)
To: Erik Gabriel Carrillo
Cc: Thomas Monjalon, Stephen Hemminger, Burakov, Anatoly,
Bruce Richardson, Ray Kinsella, dev, mw, mk, gtzalik, evgenys
On Thu, May 9, 2019 at 8:53 PM Erik Gabriel Carrillo <
erik.g.carrillo@intel.com> wrote:
> It is planned to make the rte_mem_config struct of the EAL private to
> remove it from the visible ABI. Add a notice to announce the intention.
>
> Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
> ---
> changes in v2:
> - Original deprecation notice announced a change to the rte_mem_config
> struct that would break ABI. Update the notice to instead announce
> the struct will be made private. (Stephen, Anatoly, David)
>
> doc/guides/rel_notes/deprecation.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index b47c8c2..a7dff6b 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -31,6 +31,9 @@ Deprecation Notices
>
> + ``rte_eal_devargs_type_count``
>
> +* eal: the ``rte_mem_config`` struct will be made private to remove it
> from the
> + externally visible ABI and allow it to be updated in the future.
> +
> * vfio: removal of ``rte_vfio_dma_map`` and ``rte_vfio_dma_unmap`` APIs
> which
> have been replaced with ``rte_dev_dma_map`` and ``rte_dev_dma_unmap``
> functions. The due date for the removal targets DPDK 20.02.
> --
> 2.6.4
>
>
I had a look at the current callers, trying to see what "hiding" means.
$ git grep -Elw '(rte_mem_config|mem_config)' origin/master --
origin/master:app/test/test_memzone.c
origin/master:doc/guides/rel_notes/release_18_11.rst
origin/master:drivers/bus/fslmc/fslmc_vfio.c
origin/master:drivers/net/ena/ena_ethdev.c
origin/master:drivers/net/mlx4/mlx4_mr.c
origin/master:drivers/net/mlx5/mlx5_mr.c
origin/master:drivers/net/virtio/virtio_user/virtio_user_dev.c
origin/master:lib/librte_eal/common/eal_common_memory.c
origin/master:lib/librte_eal/common/eal_common_memzone.c
origin/master:lib/librte_eal/common/eal_common_tailqs.c
origin/master:lib/librte_eal/common/include/rte_eal.h
origin/master:lib/librte_eal/common/include/rte_eal_memconfig.h
origin/master:lib/librte_eal/common/malloc_heap.c
origin/master:lib/librte_eal/common/rte_malloc.c
origin/master:lib/librte_eal/freebsd/eal/eal.c
origin/master:lib/librte_eal/freebsd/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal.c
origin/master:lib/librte_eal/linux/eal/eal_memalloc.c
origin/master:lib/librte_eal/linux/eal/eal_memory.c
origin/master:lib/librte_eal/linux/eal/eal_vfio.c
- I understand that the following drivers will need a new lock/unlock api
to protect calls to the memory api.
drivers/bus/fslmc/fslmc_vfio.c
drivers/net/mlx4/mlx4_mr.c
drivers/net/mlx5/mlx5_mr.c
drivers/net/virtio/virtio_user/virtio_user_dev.c
- I have a little trouble with this one, so there might be a new api for
this driver usecase.
A discussion will have to happen with its maintainers (added in CC:).
drivers/net/ena/ena_ethdev.c
Apart from this, I am ok with the objective, which is to hide one more eal
internal structure.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 19.05
@ 2019-05-10 14:18 6% John McNamara
2019-05-10 14:18 6% ` John McNamara
0 siblings, 1 reply; 200+ results
From: John McNamara @ 2019-05-10 14:18 UTC (permalink / raw)
To: dev; +Cc: marko.kovacevic, John McNamara
Fix grammar, spelling and formatting of DPDK 19.05 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 147 ++++++++++++++++-----------------
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 4e0eed5..fa213b5 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,24 +54,27 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
-* **Added new armv8 machine targets:**
+* **Added new armv8 machine targets.**
+
+ Added new armv8 machine targets:
* BlueField (Mellanox)
* OcteonTX2 (Marvell)
* ThunderX2 (Marvell)
-* **Introduced Windows Support.**
+* **Added Windows Support.**
Added Windows support to build Hello World sample application.
-* **Added Stack API.**
+* **Added Stack Library.**
- Added a new stack API for configuration and use of a bounded stack of
- pointers. The API provides MT-safe push and pop operations that can operate
- on one or more pointers per operation.
+ Added a new stack library and APIs for configuration and use of a bounded
+ stack of pointers. The API provides multi-thread safe push and pop
+ operations that can operate on one or more pointers per operation.
- The library supports two stack implementations: standard (lock-based) and lock-free.
- The lock-free implementation is currently limited to x86-64 platforms.
+ The library supports two stack implementations: standard (lock-based) and
+ lock-free. The lock-free implementation is currently limited to x86-64
+ platforms.
* **Added Lock-Free Stack Mempool Handler.**
@@ -80,24 +83,24 @@ New Features
* **Added RCU library.**
- Added RCU library supporting quiescent state based memory reclamation method.
+ Added RCU library supporting a 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 free data
structures.
* **Updated KNI module and PMD.**
- Updated the KNI kernel module to set the max_mtu according to the given
+ Updated the KNI kernel module to set the ``max_mtu`` according to the given
initial MTU size. Without it, the maximum MTU was 1500.
- Updated the KNI PMD driver to set the mbuf_size and MTU based on
+ Updated the KNI PMD driver to set the ``mbuf_size`` and MTU based on
the given mb-pool. This provide the ability to pass jumbo frames
- if the mb-pool contains suitable buffers' size.
+ if the mb-pool contains a suitable buffer size.
* **Added the AF_XDP PMD.**
- Added a Linux-specific PMD driver for AF_XDP, it can create the AF_XDP socket
- and bind it to a specific netdev queue, it allows a DPDK application to send
+ Added a Linux-specific PMD driver for AF_XDP. This PMD can create an AF_XDP socket
+ and bind it to a specific netdev queue. It allows a DPDK application to send
and receive raw packets through the socket which would bypass the kernel
network stack to achieve high performance packet processing.
@@ -108,21 +111,21 @@ New Features
* **Added IPN3KE net PMD.**
- Added the new ``ipn3ke`` net driver for Intel® FPGA PAC(Programmable
+ Added the new ``ipn3ke`` net driver for the Intel® FPGA PAC (Programmable
Acceleration Card) N3000. See the :doc:`../nics/ipn3ke` NIC guide for more
details on this new driver.
- Aside from this, ifpga_rawdev is also updated to support Intel® FPGA PAC
- N3000 with SPI interface access, I2C Read/Write and Ethernet PHY configuration.
+ In addition ``ifpga_rawdev`` was also updated to support Intel® FPGA PAC
+ N3000 with SPI interface access, I2C Read/Write, and Ethernet PHY configuration.
* **Updated Solarflare network PMD.**
- Updated the sfc_efx driver including the following changes:
+ Updated the Solarflare ``sfc_efx`` driver with changes including:
* Added support for Rx descriptor status and related API in a secondary
process.
* Added support for Tx descriptor status API in a secondary process.
- * Added support for RSS RETA and hash configuration get API in a secondary
+ * Added support for RSS RETA and hash configuration API in a secondary
process.
* Added support for Rx packet types list in a secondary process.
* Added Tx prepare to do Tx offloads checks.
@@ -130,27 +133,27 @@ New Features
* **Updated Mellanox mlx4 driver.**
- New features and improvements were done:
+ Updated Mellanox mlx4 driver with new features and improvements, including:
* Added firmware version reading.
- * Added support for secondary process.
- * Added support of per-process device registers, reserving identical VA space
- is not needed anymore.
- * Added support for multicast address list interface
+ * Added support for secondary processes.
+ * Added support of per-process device registers. Reserving identical VA space
+ is not required anymore.
+ * Added support for multicast address list interfaces.
* **Updated Mellanox mlx5 driver.**
- New features and improvements were done:
+ Updated Mellanox mlx5 driver with new features and improvements, including:
* Added firmware version reading.
- * Added support of new naming scheme of representor.
+ * Added support for new naming scheme of representor.
* Added support for new PCI device DMA map/unmap API.
* Added support for multiport InfiniBand device.
* Added control of excessive memory pinning by kernel.
* Added support of DMA memory registration by secondary process.
* Added Direct Rule support in Direct Verbs flow driver.
- * Added support of per-process device registers, reserving identical VA space
- is not needed anymore.
+ * Added support of per-process device registers. Reserving identical VA space
+ is not required anymore.
* Added E-Switch support in Direct Verbs flow driver.
* **Renamed avf to iavf.**
@@ -161,6 +164,8 @@ New Features
* **Updated the enic driver.**
+ Updated enic driver with new features and improvements, including:
+
* Fixed several flow (director) bugs related to MARK, SCTP, VLAN, VXLAN, and
inner packet matching.
* Added limited support for RAW.
@@ -169,12 +174,12 @@ New Features
* **Updated the ixgbe driver.**
- New features for VF:
-
- * Added promiscuous mode support.
+ Updated the ixgbe driver to add promiscuous mode support for the VF.
* **Updated the ice driver.**
+ Updated ice driver with new features and improvements, including:
+
* Added support of SSE and AVX2 instructions in Rx and Tx paths.
* Added package download support.
* Added Safe Mode support.
@@ -182,24 +187,24 @@ New Features
* **Updated the i40e driver.**
- New features for PF:
+ New features for PF in the i40e driver:
* Added support for VXLAN-GPE packet.
* Added support for VXLAN-GPE classification.
* **Updated the ENETC driver.**
- New features:
+ Updated ENETC driver with new features and improvements, including:
- * Added physical addressing mode support
- * Added SXGMII interface support
- * Added basic statistics support
- * Added promiscuous and allmulticast mode support
- * Added MTU update support
- * Added jumbo frame support
- * Added queue start/stop
- * Added CRC offload support
- * Added Rx checksum offload validation support
+ * Added physical addressing mode support.
+ * Added SXGMII interface support.
+ * Added basic statistics support.
+ * Added promiscuous and allmulticast mode support.
+ * Added MTU update support.
+ * Added jumbo frame support.
+ * Added queue start/stop.
+ * Added CRC offload support.
+ * Added Rx checksum offload validation support.
* **Updated the atlantic PMD.**
@@ -207,8 +212,9 @@ New Features
* **Updated the Intel QuickAssist Technology (QAT) compression PMD.**
- Simplified and made more robust QAT compressdev PMD's handling of SGLs with
- more than 16 segments.
+ Updated the Intel QuickAssist Technology (QAT) compression PMD to simplify,
+ and make more robust, the handling of Scatter Gather Lists (SGLs) with more
+ than 16 segments.
* **Updated the QuickAssist Technology (QAT) symmetric crypto PMD.**
@@ -216,9 +222,9 @@ New Features
* **Added Intel QuickAssist Technology PMD for asymmetric crypto.**
- A new QAT Crypto PMD has been added, which provides asymmetric cryptography
- algorithms, in this release modular exponentiation and modular multiplicative
- inverse algorithms were added.
+ Added a new QAT Crypto PMD which provides asymmetric cryptography
+ algorithms. Modular exponentiation and modular multiplicative
+ inverse algorithms were added in this release.
* **Updated AESNI-MB PMD.**
@@ -227,38 +233,25 @@ New Features
* **Updated the IPsec library.**
The IPsec library has been updated with AES-CTR and 3DES-CBC cipher algorithms
- support. The related ipsec-secgw test scripts have been added.
+ support. The related ``ipsec-secgw`` test scripts have been added.
* **Updated the testpmd application.**
- Improved testpmd application performance on ARM platform. For ``macswap``
- forwarding mode, NEON intrinsics were used to do swap to save CPU cycles.
+ Improved the ``testpmd`` application performance on ARM platform. For ``macswap``
+ forwarding mode, NEON intrinsics are now used to do swap to save CPU cycles.
* **Updated power management library.**
Added support for Intel Speed Select Technology - Base Frequency (SST-BF).
- ``rte_power_get_capabilities`` now has a bit in it's returned mask
- indicating it's a high frequency core.
+ The ``rte_power_get_capabilities`` struct now has a bit in it's returned mask
+ indicating if it is a high frequency core.
* **Updated distributor sample application.**
- Added support for Intel SST-BF feature so that the distributor core is
+ Added support for the Intel SST-BF feature so that the distributor core is
pinned to a high frequency core if available.
-Removed Items
--------------
-
-.. This section should contain removed items in this release. Sample format:
-
- * Add a short 1-2 sentence description of the removed item
- in the past tense.
-
- This section is a comment. Do not overwrite or remove it.
- Also, make sure to start the actual text at the margin.
- =========================================================
-
-
API Changes
-----------
@@ -278,10 +271,10 @@ API Changes
``rte_service_attr_get()`` has been changed
from ``uint32_t *`` to ``uint64_t *``.
-* meter: replace ``enum rte_meter_color`` in meter library with new
- ``rte_color`` definition added in 19.02. To consolidate mulitple color
- definitions replicated at many places such as: rte_mtr.h, rte_tm.h,
- replacements with rte_color values are done.
+* meter: replace ``enum rte_meter_color`` in the meter library with new
+ ``rte_color`` definition added in 19.02. Replacements with ``rte_color``
+ values has been performed in many places such as ``rte_mtr.h`` and
+ ``rte_tm.h`` to consolidate multiple color definitions.
* vfio: Functions ``rte_vfio_container_dma_map`` and
``rte_vfio_container_dma_unmap`` have been extended with an option to
@@ -291,9 +284,9 @@ API Changes
have been modified to be thread safe.
* timer: Functions have been introduced that allow multiple instances of the
- timer lists to be created, and they are now allocated in shared memory. New
- functions allow particular timer lists to be selected when timers are being
- started, stopped, and managed.
+ timer lists to be created. In addition they are now allocated in shared
+ memory. New functions allow particular timer lists to be selected when
+ timers are being started, stopped, and managed.
ABI Changes
@@ -318,8 +311,8 @@ ABI Changes
The values of these fields can be set specifically by the PMD drivers as
supported values can vary from device to device.
-* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
- included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
+* cryptodev: in 18.08 a new structure ``rte_crypto_asym_op`` was introduced and
+ included into ``rte_crypto_op``. As the ``rte_crypto_asym_op`` structure was
defined as cache-line aligned that caused unintended changes in
``rte_crypto_op`` structure layout and alignment. Remove cache-line
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
@@ -421,9 +414,9 @@ Known Issues
Also, make sure to start the actual text at the margin.
=========================================================
-* **On x86 platforms, AVX512 support is disabled with binutils 2.31**
+* **On x86 platforms, AVX512 support is disabled with binutils 2.31.**
- Because a defect in binutils 2.31 AVX512 support is disabled.
+ Due to a defect in binutils 2.31 AVX512 support is disabled.
DPDK defect: https://bugs.dpdk.org/show_bug.cgi?id=249
GCC defect: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90028
--
2.7.5
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 19.05
2019-05-10 14:18 6% [dpdk-dev] [PATCH v1] doc: update release notes for 19.05 John McNamara
@ 2019-05-10 14:18 6% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-05-10 14:18 UTC (permalink / raw)
To: dev; +Cc: marko.kovacevic, John McNamara
Fix grammar, spelling and formatting of DPDK 19.05 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 147 ++++++++++++++++-----------------
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 4e0eed5..fa213b5 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -54,24 +54,27 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
-* **Added new armv8 machine targets:**
+* **Added new armv8 machine targets.**
+
+ Added new armv8 machine targets:
* BlueField (Mellanox)
* OcteonTX2 (Marvell)
* ThunderX2 (Marvell)
-* **Introduced Windows Support.**
+* **Added Windows Support.**
Added Windows support to build Hello World sample application.
-* **Added Stack API.**
+* **Added Stack Library.**
- Added a new stack API for configuration and use of a bounded stack of
- pointers. The API provides MT-safe push and pop operations that can operate
- on one or more pointers per operation.
+ Added a new stack library and APIs for configuration and use of a bounded
+ stack of pointers. The API provides multi-thread safe push and pop
+ operations that can operate on one or more pointers per operation.
- The library supports two stack implementations: standard (lock-based) and lock-free.
- The lock-free implementation is currently limited to x86-64 platforms.
+ The library supports two stack implementations: standard (lock-based) and
+ lock-free. The lock-free implementation is currently limited to x86-64
+ platforms.
* **Added Lock-Free Stack Mempool Handler.**
@@ -80,24 +83,24 @@ New Features
* **Added RCU library.**
- Added RCU library supporting quiescent state based memory reclamation method.
+ Added RCU library supporting a 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 free data
structures.
* **Updated KNI module and PMD.**
- Updated the KNI kernel module to set the max_mtu according to the given
+ Updated the KNI kernel module to set the ``max_mtu`` according to the given
initial MTU size. Without it, the maximum MTU was 1500.
- Updated the KNI PMD driver to set the mbuf_size and MTU based on
+ Updated the KNI PMD driver to set the ``mbuf_size`` and MTU based on
the given mb-pool. This provide the ability to pass jumbo frames
- if the mb-pool contains suitable buffers' size.
+ if the mb-pool contains a suitable buffer size.
* **Added the AF_XDP PMD.**
- Added a Linux-specific PMD driver for AF_XDP, it can create the AF_XDP socket
- and bind it to a specific netdev queue, it allows a DPDK application to send
+ Added a Linux-specific PMD driver for AF_XDP. This PMD can create an AF_XDP socket
+ and bind it to a specific netdev queue. It allows a DPDK application to send
and receive raw packets through the socket which would bypass the kernel
network stack to achieve high performance packet processing.
@@ -108,21 +111,21 @@ New Features
* **Added IPN3KE net PMD.**
- Added the new ``ipn3ke`` net driver for Intel® FPGA PAC(Programmable
+ Added the new ``ipn3ke`` net driver for the Intel® FPGA PAC (Programmable
Acceleration Card) N3000. See the :doc:`../nics/ipn3ke` NIC guide for more
details on this new driver.
- Aside from this, ifpga_rawdev is also updated to support Intel® FPGA PAC
- N3000 with SPI interface access, I2C Read/Write and Ethernet PHY configuration.
+ In addition ``ifpga_rawdev`` was also updated to support Intel® FPGA PAC
+ N3000 with SPI interface access, I2C Read/Write, and Ethernet PHY configuration.
* **Updated Solarflare network PMD.**
- Updated the sfc_efx driver including the following changes:
+ Updated the Solarflare ``sfc_efx`` driver with changes including:
* Added support for Rx descriptor status and related API in a secondary
process.
* Added support for Tx descriptor status API in a secondary process.
- * Added support for RSS RETA and hash configuration get API in a secondary
+ * Added support for RSS RETA and hash configuration API in a secondary
process.
* Added support for Rx packet types list in a secondary process.
* Added Tx prepare to do Tx offloads checks.
@@ -130,27 +133,27 @@ New Features
* **Updated Mellanox mlx4 driver.**
- New features and improvements were done:
+ Updated Mellanox mlx4 driver with new features and improvements, including:
* Added firmware version reading.
- * Added support for secondary process.
- * Added support of per-process device registers, reserving identical VA space
- is not needed anymore.
- * Added support for multicast address list interface
+ * Added support for secondary processes.
+ * Added support of per-process device registers. Reserving identical VA space
+ is not required anymore.
+ * Added support for multicast address list interfaces.
* **Updated Mellanox mlx5 driver.**
- New features and improvements were done:
+ Updated Mellanox mlx5 driver with new features and improvements, including:
* Added firmware version reading.
- * Added support of new naming scheme of representor.
+ * Added support for new naming scheme of representor.
* Added support for new PCI device DMA map/unmap API.
* Added support for multiport InfiniBand device.
* Added control of excessive memory pinning by kernel.
* Added support of DMA memory registration by secondary process.
* Added Direct Rule support in Direct Verbs flow driver.
- * Added support of per-process device registers, reserving identical VA space
- is not needed anymore.
+ * Added support of per-process device registers. Reserving identical VA space
+ is not required anymore.
* Added E-Switch support in Direct Verbs flow driver.
* **Renamed avf to iavf.**
@@ -161,6 +164,8 @@ New Features
* **Updated the enic driver.**
+ Updated enic driver with new features and improvements, including:
+
* Fixed several flow (director) bugs related to MARK, SCTP, VLAN, VXLAN, and
inner packet matching.
* Added limited support for RAW.
@@ -169,12 +174,12 @@ New Features
* **Updated the ixgbe driver.**
- New features for VF:
-
- * Added promiscuous mode support.
+ Updated the ixgbe driver to add promiscuous mode support for the VF.
* **Updated the ice driver.**
+ Updated ice driver with new features and improvements, including:
+
* Added support of SSE and AVX2 instructions in Rx and Tx paths.
* Added package download support.
* Added Safe Mode support.
@@ -182,24 +187,24 @@ New Features
* **Updated the i40e driver.**
- New features for PF:
+ New features for PF in the i40e driver:
* Added support for VXLAN-GPE packet.
* Added support for VXLAN-GPE classification.
* **Updated the ENETC driver.**
- New features:
+ Updated ENETC driver with new features and improvements, including:
- * Added physical addressing mode support
- * Added SXGMII interface support
- * Added basic statistics support
- * Added promiscuous and allmulticast mode support
- * Added MTU update support
- * Added jumbo frame support
- * Added queue start/stop
- * Added CRC offload support
- * Added Rx checksum offload validation support
+ * Added physical addressing mode support.
+ * Added SXGMII interface support.
+ * Added basic statistics support.
+ * Added promiscuous and allmulticast mode support.
+ * Added MTU update support.
+ * Added jumbo frame support.
+ * Added queue start/stop.
+ * Added CRC offload support.
+ * Added Rx checksum offload validation support.
* **Updated the atlantic PMD.**
@@ -207,8 +212,9 @@ New Features
* **Updated the Intel QuickAssist Technology (QAT) compression PMD.**
- Simplified and made more robust QAT compressdev PMD's handling of SGLs with
- more than 16 segments.
+ Updated the Intel QuickAssist Technology (QAT) compression PMD to simplify,
+ and make more robust, the handling of Scatter Gather Lists (SGLs) with more
+ than 16 segments.
* **Updated the QuickAssist Technology (QAT) symmetric crypto PMD.**
@@ -216,9 +222,9 @@ New Features
* **Added Intel QuickAssist Technology PMD for asymmetric crypto.**
- A new QAT Crypto PMD has been added, which provides asymmetric cryptography
- algorithms, in this release modular exponentiation and modular multiplicative
- inverse algorithms were added.
+ Added a new QAT Crypto PMD which provides asymmetric cryptography
+ algorithms. Modular exponentiation and modular multiplicative
+ inverse algorithms were added in this release.
* **Updated AESNI-MB PMD.**
@@ -227,38 +233,25 @@ New Features
* **Updated the IPsec library.**
The IPsec library has been updated with AES-CTR and 3DES-CBC cipher algorithms
- support. The related ipsec-secgw test scripts have been added.
+ support. The related ``ipsec-secgw`` test scripts have been added.
* **Updated the testpmd application.**
- Improved testpmd application performance on ARM platform. For ``macswap``
- forwarding mode, NEON intrinsics were used to do swap to save CPU cycles.
+ Improved the ``testpmd`` application performance on ARM platform. For ``macswap``
+ forwarding mode, NEON intrinsics are now used to do swap to save CPU cycles.
* **Updated power management library.**
Added support for Intel Speed Select Technology - Base Frequency (SST-BF).
- ``rte_power_get_capabilities`` now has a bit in it's returned mask
- indicating it's a high frequency core.
+ The ``rte_power_get_capabilities`` struct now has a bit in it's returned mask
+ indicating if it is a high frequency core.
* **Updated distributor sample application.**
- Added support for Intel SST-BF feature so that the distributor core is
+ Added support for the Intel SST-BF feature so that the distributor core is
pinned to a high frequency core if available.
-Removed Items
--------------
-
-.. This section should contain removed items in this release. Sample format:
-
- * Add a short 1-2 sentence description of the removed item
- in the past tense.
-
- This section is a comment. Do not overwrite or remove it.
- Also, make sure to start the actual text at the margin.
- =========================================================
-
-
API Changes
-----------
@@ -278,10 +271,10 @@ API Changes
``rte_service_attr_get()`` has been changed
from ``uint32_t *`` to ``uint64_t *``.
-* meter: replace ``enum rte_meter_color`` in meter library with new
- ``rte_color`` definition added in 19.02. To consolidate mulitple color
- definitions replicated at many places such as: rte_mtr.h, rte_tm.h,
- replacements with rte_color values are done.
+* meter: replace ``enum rte_meter_color`` in the meter library with new
+ ``rte_color`` definition added in 19.02. Replacements with ``rte_color``
+ values has been performed in many places such as ``rte_mtr.h`` and
+ ``rte_tm.h`` to consolidate multiple color definitions.
* vfio: Functions ``rte_vfio_container_dma_map`` and
``rte_vfio_container_dma_unmap`` have been extended with an option to
@@ -291,9 +284,9 @@ API Changes
have been modified to be thread safe.
* timer: Functions have been introduced that allow multiple instances of the
- timer lists to be created, and they are now allocated in shared memory. New
- functions allow particular timer lists to be selected when timers are being
- started, stopped, and managed.
+ timer lists to be created. In addition they are now allocated in shared
+ memory. New functions allow particular timer lists to be selected when
+ timers are being started, stopped, and managed.
ABI Changes
@@ -318,8 +311,8 @@ ABI Changes
The values of these fields can be set specifically by the PMD drivers as
supported values can vary from device to device.
-* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
- included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
+* cryptodev: in 18.08 a new structure ``rte_crypto_asym_op`` was introduced and
+ included into ``rte_crypto_op``. As the ``rte_crypto_asym_op`` structure was
defined as cache-line aligned that caused unintended changes in
``rte_crypto_op`` structure layout and alignment. Remove cache-line
alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
@@ -421,9 +414,9 @@ Known Issues
Also, make sure to start the actual text at the margin.
=========================================================
-* **On x86 platforms, AVX512 support is disabled with binutils 2.31**
+* **On x86 platforms, AVX512 support is disabled with binutils 2.31.**
- Because a defect in binutils 2.31 AVX512 support is disabled.
+ Due to a defect in binutils 2.31 AVX512 support is disabled.
DPDK defect: https://bugs.dpdk.org/show_bug.cgi?id=249
GCC defect: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90028
--
2.7.5
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup
2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-09 10:08 0% ` Burakov, Anatoly
@ 2019-05-10 14:42 0% ` Stephen Hemminger
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-05-10 14:42 UTC (permalink / raw)
To: Burakov, Anatoly
Cc: Ray Kinsella, Thomas Monjalon, Bruce Richardson, David Marchand,
Erik Gabriel Carrillo, dev
On Thu, 9 May 2019 11:08:30 +0100
"Burakov, Anatoly" <anatoly.burakov@intel.com> wrote:
> On 09-May-19 10:50 AM, Ray Kinsella wrote:
> >
> >
> > On 09/05/2019 10:38, Thomas Monjalon wrote:
> >> 09/05/2019 11:37, Burakov, Anatoly:
> >>> On 09-May-19 10:06 AM, Bruce Richardson wrote:
> >>>> On Thu, May 09, 2019 at 09:33:32AM +0100, Burakov, Anatoly wrote:
> >>>>> On 09-May-19 8:05 AM, David Marchand wrote:
> >>>>>> On Thu, May 9, 2019 at 3:11 AM Stephen Hemminger
> >>>>>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote:
> >>>>>>
> >>>>>> On Wed, 8 May 2019 17:48:06 -0500
> >>>>>> Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>>>> <mailto:erik.g.carrillo@intel.com>> wrote:
> >>>>>>
> >>>>>> > Due to an upcoming fix to allow the timer library to safely free its
> >>>>>> > allocations during the finalize() call[1], an ABI change will be
> >>>>>> > required. A new lock will be added to the rte_mem_config structure,
> >>>>>> > which will be used by the timer library to synchronize init/finalize
> >>>>>> > calls among multiple processes.
> >>>>>> >
> >>>>>> > [1] http://patches.dpdk.org/patch/53334/
> >>>>>> >
> >>>>>> > Signed-off-by: Erik Gabriel Carrillo <erik.g.carrillo@intel.com
> >>>>>> <mailto:erik.g.carrillo@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 b47c8c2..7551383 100644
> >>>>>> > --- a/doc/guides/rel_notes/deprecation.rst
> >>>>>> > +++ b/doc/guides/rel_notes/deprecation.rst
> >>>>>> > @@ -31,6 +31,10 @@ Deprecation Notices
> >>>>>> >
> >>>>>> > + ``rte_eal_devargs_type_count``
> >>>>>> >
> >>>>>> > +* eal: the ``rte_mem_config`` struct will change to include a
> >>>>>> new lock that
> >>>>>> > + will allow the timer subsystem to safely release its
> >>>>>> allocations at cleanup
> >>>>>> > + time. This will result in an ABI break.
> >>>>>> > +
> >>>>>> > * vfio: removal of ``rte_vfio_dma_map`` and
> >>>>>> ``rte_vfio_dma_unmap`` APIs which
> >>>>>> > have been replaced with ``rte_dev_dma_map`` and
> >>>>>> ``rte_dev_dma_unmap``
> >>>>>> > functions. The due date for the removal targets DPDK 20.02.
> >>>>>>
> >>>>>> NAK
> >>>>>>
> >>>>>> Please go to the effort of making rte_mem_config not part of the
> >>>>>> visible ABI.
> >>>>>> Then change it.
> >>>>>>
> >>>>>>
> >>>>>> +1.
> >>>>>
> >>>>> I agree on principle, however this won't solve the issue. It doesn't need to
> >>>>> be externally visible, but that's not all of its problems - it's also shared
> >>>>> between processes so there's an ABI contract between primary and secondary
> >>>>> too. This means that, even if the structure itself is not public, any
> >>>>> changes to it will still result in an ABI break. That's the nature of our
> >>>>> shared memory.
> >>>>>
> >>>>> In other words, if your goal is to avoid ABI breaks on changing this
> >>>>> structure, making it internal won't help in the slightest.
> >>>>>
> >>>>
> >>>> Is there an ABI contract between primary and secondary. I always assumed
> >>>> that if using secondary processes the requirement (though undocumented) was
> >>>> that both had to be linked against the exact same versions of DPDK?
> >>>>
> >>>
> >>> The fact that it's undocumented means we can't assume everyone will do
> >>> that :)
> >>>
> >>> If the community agrees that primary/secondary processes should always
> >>> use the same DPDK version (regardless of static/dynamic builds etc.),
> >>> then this problem would probably be solved.
> >>
> >> +1 to document that primary/secondary with different DPDK versions
> >> is not supported.
> >>
> >
> > +1,
> >
> > but I think we need to go farther - we need a secondary process to check
> > with the primary process.
> > We can't assume everyone will read the documentation.
> >
>
> That easily can be done, yes.
>
FYI - I submitted patches to make lcore_config private.
These patches should handle mem_config.
And I started on making eal_config private (but mem_config got in the way).
Other candidates are the internals behind ethdev and devices.
^ permalink raw reply [relevance 0%]
Results 5601-5800 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
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 ` Stephen Hemminger
2019-04-12 22:24 ` Honnappa Nagarahalli
2019-04-12 23:06 ` Stephen Hemminger
2019-04-15 12:24 ` Ananyev, Konstantin
2019-04-15 15:38 ` Stephen Hemminger
2019-04-15 17:39 ` Ananyev, Konstantin
2019-04-15 21:26 ` Stephen Hemminger
2019-04-16 5:29 ` Honnappa Nagarahalli
2019-04-16 14:54 ` Stephen Hemminger
2019-04-16 16:56 ` Honnappa Nagarahalli
2019-04-16 21:22 ` Stephen Hemminger
2019-04-17 1:45 ` 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-13 19:21 [dpdk-dev] [PATCH 1/1] doc: announce change in power API Hajkowski
2019-04-18 14:33 ` Hunt, David
2019-05-09 23:28 ` Thomas Monjalon
2019-05-10 9:28 ` Bruce Richardson
2019-05-10 9:33 3% ` Bruce Richardson
2019-05-10 9:33 3% ` Bruce Richardson
2019-04-08 18:25 [dpdk-dev] [PATCH v1 0/5] make lcore_config internal Stephen Hemminger
2019-04-10 17:15 ` [dpdk-dev] [PATCH v2 " Stephen Hemminger
2019-04-10 17:16 ` [dpdk-dev] [PATCH v2 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-05-03 7:22 0% ` David Marchand
2019-05-03 7:22 0% ` David Marchand
2019-05-02 23:15 0% ` [dpdk-dev] [PATCH v2 0/5] make lcore_config internal Stephen Hemminger
2019-05-02 23:15 0% ` Stephen Hemminger
2019-05-03 17:25 8% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI Stephen Hemminger
2019-05-03 17:25 8% ` Stephen Hemminger
2019-05-03 17:25 9% ` [dpdk-dev] [PATCH v3 2/5] eal: add accessor functions for lcore_config Stephen Hemminger
2019-05-03 17:25 9% ` Stephen Hemminger
2019-05-06 7:20 4% ` [dpdk-dev] [PATCH v3 0/5] prepare to make lcore_config not visible in ABI David Marchand
2019-05-06 7:20 4% ` David Marchand
2019-04-10 11:26 [dpdk-dev] [PATCH v3 0/3] add actions to modify header fields Dekel Peled
2019-04-10 11:50 ` [dpdk-dev] [PATCH v4 " Dekel Peled
2019-04-10 11:50 ` [dpdk-dev] [PATCH v4 1/3] ethdev: add actions to modify TCP " Dekel Peled
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-18 12:30 3% ` Adrien Mazarguil
2019-04-22 7:15 0% ` Dekel Peled
2019-04-22 7:15 0% ` Dekel Peled
2019-04-17 5:12 [dpdk-dev] ABI and inline functions Honnappa Nagarahalli
2019-04-17 5:12 9% ` Honnappa Nagarahalli
2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 8:36 8% ` Bruce Richardson
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 16:52 4% ` Stephen Hemminger
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 17:46 7% ` Jerin Jacob Kollanukkaran
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-17 18:51 4% ` Stephen Hemminger
2019-04-18 5:56 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-18 5:56 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-23 14:23 4% ` Ray Kinsella
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
2019-04-24 18:38 4% ` Jerin Jacob Kollanukkaran
2019-04-23 14:19 4% ` [dpdk-dev] " Ray Kinsella
2019-04-23 14:19 4% ` Ray Kinsella
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 4:34 9% ` Honnappa Nagarahalli
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-18 10:28 7% ` Bruce Richardson
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-23 14:12 4% ` Ray Kinsella
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 5:15 7% ` Honnappa Nagarahalli
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 11:08 8% ` Burakov, Anatoly
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:22 9% ` Ray Kinsella
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 12:54 4% ` Burakov, Anatoly
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-24 15:44 4% ` Stephen Hemminger
2019-04-30 8:52 9% ` Thomas Monjalon
2019-04-30 8:52 9% ` Thomas Monjalon
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 5:08 7% ` Honnappa Nagarahalli
2019-04-24 8:49 4% ` Bruce Richardson
2019-04-24 8:49 4% ` Bruce Richardson
2019-04-18 10:58 3% [dpdk-dev] DPDK Release Status Meeting 18/4/2019 Ferruh Yigit
2019-04-18 10:58 3% ` Ferruh Yigit
2019-04-18 20:41 5% [dpdk-dev] DPDK techboard minutes (2019-04-10) Olivier Matz
2019-04-18 20:41 5% ` Olivier Matz
2019-04-19 21:21 [dpdk-dev] [RFC v2 1/2] eal: replace libc-based random number generation with LFSR Mattias Rönnblom
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 11:34 3% ` Neil Horman
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 14:49 0% ` Stephen Hemminger
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 15:52 3% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-22 17:44 0% ` Mattias Rönnblom
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 11:33 3% ` Neil Horman
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-23 17:13 0% ` Mattias Rönnblom
2019-04-24 11:37 0% ` Neil Horman
2019-04-24 11:37 0% ` Neil Horman
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 15:31 0% ` Stephen Hemminger
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-23 17:17 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-24 7:52 0% ` Mattias Rönnblom
2019-04-23 23:16 3% [dpdk-dev] DPDK Windows Community call - 18 April 2019 Ranjit Menon
2019-04-23 23:16 3% ` Ranjit Menon
2019-04-24 8:18 20% [dpdk-dev] [DPDK] changed default-target from linux to linuxapp for back-compatibility of validate-abi.sh Peng Huang
2019-04-24 8:18 20% ` Peng Huang
2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 8:56 4% ` Bruce Richardson
2019-04-24 15:11 22% [dpdk-dev] [DPDK] devtools: change for ABI back-compatibility checking Peng Huang
2019-04-24 12:08 4% ` Neil Horman
2019-04-24 12:08 4% ` Neil Horman
2019-05-01 23:47 4% ` Thomas Monjalon
2019-05-01 23:47 4% ` Thomas Monjalon
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 12:32 4% ` Bruce Richardson
2019-04-24 15:11 22% ` Peng Huang
2019-04-25 11:10 [dpdk-dev] [PATCH v2] vhost: support inflight share memory protocol feature Li Lin
2019-04-26 9:40 ` [dpdk-dev] [PATCH v3] " Li Lin
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-28 11:17 3% ` Tiwei Bie
2019-04-29 4:07 0% ` lin li
2019-04-29 4:07 0% ` lin li
2019-04-26 15:14 1% [dpdk-dev] [PATCH v2 1/2] doc: fix spelling errors reported by aspell John McNamara
2019-04-26 15:14 1% ` John McNamara
2019-04-28 14:58 4% [dpdk-dev] [PATCH] doc: announce ABI change on eal and kni Arnon Warshavsky
2019-04-28 14:58 4% ` Arnon Warshavsky
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-28 16:23 4% ` Stephen Hemminger
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 9:28 4% ` Ferruh Yigit
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 16:24 4% ` Stephen Hemminger
2019-04-29 17:19 4% ` Ferruh Yigit
2019-04-29 17:19 4% ` Ferruh Yigit
2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-07 9:57 4% ` Arnon Warshavsky
2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 11:07 4% ` Thomas Monjalon
2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:22 4% ` Arnon Warshavsky
2019-05-08 20:25 4% ` Thomas Monjalon
2019-05-08 20:25 4% ` Thomas Monjalon
2019-05-01 19:00 [dpdk-dev] [PATCH] timer: fix resource leak in finalize Erik Gabriel Carrillo
2019-05-03 22:54 ` [dpdk-dev] [PATCH v2] " Erik Gabriel Carrillo
2019-05-07 11:03 ` Burakov, Anatoly
2019-05-07 22:04 ` Carrillo, Erik G
2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 8:49 3% ` Burakov, Anatoly
2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-08 23:01 3% ` Carrillo, Erik G
2019-05-09 7:44 0% ` Thomas Monjalon
2019-05-09 7:44 0% ` Thomas Monjalon
2019-05-08 22:35 ` [dpdk-dev] [PATCH v3] " Erik Gabriel Carrillo
2019-05-09 8:29 3% ` Burakov, Anatoly
2019-05-09 8:29 3% ` Burakov, Anatoly
2019-05-02 9:33 [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30 Reshma Pattan
2019-05-02 14:13 ` [dpdk-dev] [PATCH v2] mk: report address of packed member as warning Reshma Pattan
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 15:53 3% ` Burakov, Anatoly
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-02 18:54 0% ` Stephen Hemminger
2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-03 7:56 0% ` Burakov, Anatoly
2019-05-02 15:00 ` [dpdk-dev] [PATCH] mk: disable warning with gcc 9 on Fedora 30 David Marchand
2019-05-02 15:56 ` Thomas Monjalon
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:01 3% ` Jerin Jacob Kollanukkaran
2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:25 0% ` Bruce Richardson
2019-05-03 16:28 0% ` Richardson, Bruce
2019-05-03 16:28 0% ` Richardson, Bruce
2019-05-03 17:24 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-05-03 17:24 0% ` Jerin Jacob Kollanukkaran
2019-05-03 14:34 [dpdk-dev] [PATCH 1/4] devtools: do not complain when reordering symbols David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 2/4] devtools: handle section suppression David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 15:03 0% ` Neil Horman
2019-05-03 15:03 0% ` Neil Horman
2019-05-03 17:16 0% ` David Marchand
2019-05-03 17:16 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
2019-05-06 12:56 0% ` David Marchand
2019-05-06 15:43 0% ` Neil Horman
2019-05-06 15:43 0% ` Neil Horman
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 3/4] devtools: fix symbol name in log message David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-03 14:34 3% ` [dpdk-dev] [PATCH 4/4] devtools: fix direct additions to stable API David Marchand
2019-05-03 14:34 3% ` David Marchand
2019-05-09 21:40 0% ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-05-09 21:40 0% ` Thomas Monjalon
2019-05-06 21:29 10% [dpdk-dev] [PATCH] doc: update release notes for timer library changes Erik Gabriel Carrillo
2019-05-06 21:29 10% ` Erik Gabriel Carrillo
2019-05-08 22:48 8% [dpdk-dev] [PATCH] doc: add deprecation notice on timer lib cleanup Erik Gabriel Carrillo
2019-05-08 22:48 8% ` Erik Gabriel Carrillo
2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 1:11 3% ` Stephen Hemminger
2019-05-09 7:05 0% ` David Marchand
2019-05-09 7:05 0% ` David Marchand
2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 8:33 4% ` Burakov, Anatoly
2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:06 3% ` Bruce Richardson
2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:37 0% ` Burakov, Anatoly
2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:38 0% ` Thomas Monjalon
2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 9:50 0% ` Ray Kinsella
2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-09 10:08 0% ` Burakov, Anatoly
2019-05-10 14:42 0% ` Stephen Hemminger
2019-05-09 11:53 0% ` Burakov, Anatoly
2019-05-09 11:53 0% ` Burakov, Anatoly
2019-05-09 18:51 9% ` [dpdk-dev] [PATCH v2] doc: add deprecation notice on EAL mem config Erik Gabriel Carrillo
2019-05-09 18:51 9% ` Erik Gabriel Carrillo
2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:31 0% ` Burakov, Anatoly
2019-05-10 9:34 0% ` Bruce Richardson
2019-05-10 9:34 0% ` Bruce Richardson
2019-05-10 13:44 0% ` David Marchand
2019-05-10 13:44 0% ` David Marchand
2019-05-09 23:34 3% [dpdk-dev] DPDK Windows Community call - 02 May 2019 Ranjit Menon
2019-05-09 23:34 3% ` Ranjit Menon
2019-05-10 13:01 4% [dpdk-dev] Discussion on the OS Packaging of DPDK Ray Kinsella
2019-05-10 13:01 4% ` Ray Kinsella
2019-05-10 13:43 0% ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-05-10 13:43 0% ` Bruce Richardson
2019-05-10 14:18 6% [dpdk-dev] [PATCH v1] doc: update release notes for 19.05 John McNamara
2019-05-10 14:18 6% ` John McNamara
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).