* Re: [PATCH v2] net/ring: remove unnecessary NULL check
From: Ferruh Yigit @ 2016-11-02 11:38 UTC (permalink / raw)
To: Mauricio Vasquez B, bruce.richardson; +Cc: dev
In-Reply-To: <1478030140-7127-1-git-send-email-mauricio.vasquez@polito.it>
Hi Mauricio,
On 11/1/2016 7:55 PM, Mauricio Vasquez B wrote:
> Coverity detected this as an issue because internals->data will never be NULL,
> then the check is not necessary.
>
> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
> Coverity issue: 137873
>
> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
> ---
> drivers/net/ring/rte_eth_ring.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
> index 6d2a8c1..5ca00ed 100644
> --- a/drivers/net/ring/rte_eth_ring.c
> +++ b/drivers/net/ring/rte_eth_ring.c
> @@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
>
> eth_dev_stop(eth_dev);
>
> - if (eth_dev->data) {
> - internals = eth_dev->data->dev_private;
> - if (internals->action == DEV_CREATE) {
> - /*
> - * it is only necessary to delete the rings in rx_queues because
> - * they are the same used in tx_queues
> - */
> - for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> - r = eth_dev->data->rx_queues[i];
> - rte_ring_free(r->rng);
> - }
> + internals = eth_dev->data->dev_private;
> + if (internals->action == DEV_CREATE) {
> + /*
> + * it is only necessary to delete the rings in rx_queues because
> + * they are the same used in tx_queues
> + */
> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> + r = eth_dev->data->rx_queues[i];
> + rte_ring_free(r->rng);
> }
>
> rte_free(eth_dev->data->rx_queues);
This patch not only removes the NULL check but also changes the logic.
after patch rx_queues, tx_queues and dev_private only freed if action is
DEV_CREATE which is wrong.
>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Bruce Richardson @ 2016-11-02 11:45 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102104702.GA30658@localhost.localdomain>
On Wed, Nov 02, 2016 at 04:17:04PM +0530, Jerin Jacob wrote:
> On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote:
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > >
> > > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > > Let me know, if anyone else interested in contributing to the definition of eventdev?
> > >
> > > If there are no major issues in proposed spec, then Cavium would like work on
> > > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > > an associated HW driver.(Requested minor changes of v2 will be addressed
> > > in next version).
> >
>
> Hi All,
>
> Two queries,
>
> 1) In SW implementation, Is their any connection between "struct
> rte_event_port_conf"'s dequeue_queue_depth and enqueue_queue_depth ?
> i.e it should be enqueue_queue_depth >= dequeue_queue_depth. Right ?
> Thought of adding the common checks in common layer.
I think this is probably best left to the driver layers to enforce. For
us, such a restriction doesn't really make sense, though in many cases
that would be the usual setup. For accurate load balancing, the dequeue
queue depth would be small, and the burst size would probably equal the
queue depth, meaning the enqueue depth needs to be at least as big.
However, for better throughput, or in cases where all traffic is being
coalesced to a single core e.g. for transmit out a network port, there
is no need to keep the dequeue queue shallow and so it can be many times
the burst size, while the enqueue queue can be kept to 1-2 times the
burst size.
>
> 2)Any comments on follow item(section under ----) that needs improvement.
> -------------------------------------------------------------------------------
> Abstract the differences in event QoS management with different
> priority schemes available in different HW or SW implementations with portable
> application workflow.
>
> Based on the feedback, there three different kinds of QoS support
> available in
> three different HW or SW implementations.
> 1) Priority associated with the event queue
> 2) Priority associated with each event enqueue
> (Same flow can have two different priority on two separate enqueue)
> 3) Priority associated with the flow(each flow has unique priority)
>
> In v2, The differences abstracted based on device capability
> (RTE_EVENT_DEV_CAP_QUEUE_QOS for the first scheme,
> RTE_EVENT_DEV_CAP_EVENT_QOS for the second and third scheme).
> This scheme would call for different application workflow for
> nontrivial QoS-enabled applications.
> -------------------------------------------------------------------------------
> After thinking a while, I think, RTE_EVENT_DEV_CAP_EVENT_QOS is a
> super-set.if so, the subset RTE_EVENT_DEV_CAP_QUEUE_QOS can be
> implemented with RTE_EVENT_DEV_CAP_EVENT_QOS. i.e We may not need two
> flags, Just one flag RTE_EVENT_DEV_CAP_EVENT_QOS is enough to fix
> portability issue with basic QoS enabled applications.
>
> i.e Introduce RTE_EVENT_DEV_CAP_EVENT_QOS as config option in device
> configure stage if application needs fine granularity on QoS per event
> enqueue.For trivial applications, configured
> rte_event_queue_conf->priority can be used as rte_event_enqueue(struct
> rte_event.priority)
>
So all implementations should support the concept of priority among
queues, and then there is optional support for event or flow based
prioritization. Is that a correct interpretation of what you propose?
/Bruce
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Bruce Richardson @ 2016-11-02 11:48 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102080632.GA21820@localhost.localdomain>
On Wed, Nov 02, 2016 at 01:36:34PM +0530, Jerin Jacob wrote:
> On Fri, Oct 28, 2016 at 01:48:57PM +0000, Van Haaren, Harry wrote:
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Tuesday, October 25, 2016 6:49 PM
> > <snip>
> > >
> > > Hi Community,
> > >
> > > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > > Let me know, if anyone else interested in contributing to the definition of eventdev?
> > >
> > > If there are no major issues in proposed spec, then Cavium would like work on
> > > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > > an associated HW driver.(Requested minor changes of v2 will be addressed
> > > in next version).
> >
> >
> > Hi All,
> >
> > I've been looking at the eventdev API from a use-case point of view, and I'm unclear on a how the API caters for two uses. I have simplified these as much as possible, think of them as a theoretical unit-test for the API :)
> >
> >
> > Fragmentation:
> > 1. Dequeue 8 packets
> > 2. Process 2 packets
> > 3. Processing 3rd, this packet needs fragmentation into two packets
> > 4. Process remaining 5 packets as normal
> >
> > What function calls does the application make to achieve this?
> > In particular, I'm referring to how can the scheduler know that the 3rd packet is the one being fragmented, and how to keep packet order valid.
> >
>
> OK. I will try to share my views on IP fragmentation on event _HW_
> models(at least on Cavium HW) then we can see, how we can converge.
>
> First, The fragmentation specific logic should be decoupled from the event
> model as it specific to packet and L3 layer(Not specific to generic event)
>
I would view fragmentation as just one example of a workload like this,
multicast and broadcast may be two other cases. Yes, they all apply to
packet, but the general feature support is just how to provide support
for one event generating multiple further events which should be linked
together for reordering. [I think this only really applies in the
reordered case - which leads to another question: in your experience
do you see other event types other than packet being handled in a
"reordered" manner?]
/Bruce
^ permalink raw reply
* Re: Best Practices for PMD Verification before Upstream Requests
From: Shepard Siegel @ 2016-11-02 12:21 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
In-Reply-To: <2866322.PnTaiuzzpn@xps13>
Thomas and DPDK devs,
Almost a year into our DPDK development, we have shipped an alpha version
of our "Arkville" product. We've thankful for all the support from this
group. Most everyone has suggested "get your code upstream ASAP"; but our
team is cut from the "if it isn't tested, it doesn't work" cloth. We now
have some solid miles on our Arkville PMD driver "ark" with 16.07. Mostly
testpmd and a suite of user apps; dts not so much, only because our use
case is a little different. We expect almost all of our contribution would
land under $dpdk/drivers/net/ark . We are looking past 16.11 to possibly
jump on board when the 17.02 window opens in December. One question that
came up is "Should we do a thorough port and regression against 16.11 as a
precursor to up streaming at 17.02?". Constructive feedback always welcome!
-Shep
Shepard Siegel, CTO
atomicrules.com
On Mon, Aug 22, 2016 at 9:07 AM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:
> 2016-08-17 08:34, Shepard Siegel:
> > Atomic Rules is new to the DPDK community. We attended the DPDK Summit
> last
> > week and received terrific advice and encouragement. We are developing a
> > DPDK PMD for our Arkville product which is a DPDK-aware data mover,
> capable
> > of marshaling packets between FPGA/ASIC gates with AXI interfaces on one
> > side, and the DPDK API/ABI on the other. Arkville plus a MAC looks like a
> > line-rate-agnostic bare-bones L2 NIC. We have testpmd and our first DPDK
> > applications running using our early-alpha Arkville PMD.
>
> Welcome :)
>
> Any release targeted for upstream support?
>
> <snip>
>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-11-02 12:34 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102114506.GB40328@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Nov 02, 2016 at 11:45:07AM +0000, Bruce Richardson wrote:
> On Wed, Nov 02, 2016 at 04:17:04PM +0530, Jerin Jacob wrote:
> > On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote:
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > >
> > > > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > > > Let me know, if anyone else interested in contributing to the definition of eventdev?
> > > >
> > > > If there are no major issues in proposed spec, then Cavium would like work on
> > > > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > > > an associated HW driver.(Requested minor changes of v2 will be addressed
> > > > in next version).
> > >
> >
> > Hi All,
> >
> > Two queries,
> >
> > 1) In SW implementation, Is their any connection between "struct
> > rte_event_port_conf"'s dequeue_queue_depth and enqueue_queue_depth ?
> > i.e it should be enqueue_queue_depth >= dequeue_queue_depth. Right ?
> > Thought of adding the common checks in common layer.
>
> I think this is probably best left to the driver layers to enforce. For
> us, such a restriction doesn't really make sense, though in many cases
> that would be the usual setup. For accurate load balancing, the dequeue
> queue depth would be small, and the burst size would probably equal the
> queue depth, meaning the enqueue depth needs to be at least as big.
> However, for better throughput, or in cases where all traffic is being
> coalesced to a single core e.g. for transmit out a network port, there
> is no need to keep the dequeue queue shallow and so it can be many times
> the burst size, while the enqueue queue can be kept to 1-2 times the
> burst size.
>
OK
> >
> > 2)Any comments on follow item(section under ----) that needs improvement.
> > -------------------------------------------------------------------------------
> > Abstract the differences in event QoS management with different
> > priority schemes available in different HW or SW implementations with portable
> > application workflow.
> >
> > Based on the feedback, there three different kinds of QoS support
> > available in
> > three different HW or SW implementations.
> > 1) Priority associated with the event queue
> > 2) Priority associated with each event enqueue
> > (Same flow can have two different priority on two separate enqueue)
> > 3) Priority associated with the flow(each flow has unique priority)
> >
> > In v2, The differences abstracted based on device capability
> > (RTE_EVENT_DEV_CAP_QUEUE_QOS for the first scheme,
> > RTE_EVENT_DEV_CAP_EVENT_QOS for the second and third scheme).
> > This scheme would call for different application workflow for
> > nontrivial QoS-enabled applications.
> > -------------------------------------------------------------------------------
> > After thinking a while, I think, RTE_EVENT_DEV_CAP_EVENT_QOS is a
> > super-set.if so, the subset RTE_EVENT_DEV_CAP_QUEUE_QOS can be
> > implemented with RTE_EVENT_DEV_CAP_EVENT_QOS. i.e We may not need two
> > flags, Just one flag RTE_EVENT_DEV_CAP_EVENT_QOS is enough to fix
> > portability issue with basic QoS enabled applications.
> >
> > i.e Introduce RTE_EVENT_DEV_CAP_EVENT_QOS as config option in device
> > configure stage if application needs fine granularity on QoS per event
> > enqueue.For trivial applications, configured
> > rte_event_queue_conf->priority can be used as rte_event_enqueue(struct
> > rte_event.priority)
> >
> So all implementations should support the concept of priority among
> queues, and then there is optional support for event or flow based
> prioritization. Is that a correct interpretation of what you propose?
Yes. If you _can_ implement it and if possible in the system.
>
> /Bruce
>
^ permalink raw reply
* Re: [PATCH v2] net/ring: remove unnecessary NULL check
From: Fulvio Risso @ 2016-11-02 12:49 UTC (permalink / raw)
To: Ferruh Yigit, Mauricio Vasquez B, bruce.richardson; +Cc: dev
In-Reply-To: <6c7a2a77-7370-3550-7aad-d98327f033ba@intel.com>
Dear Ferruh,
Maybe I'm wrong, but I cannot see your point.
The code is absolutely the same, only the following line
if (eth_dev->data) {
is actually removed.
fulvio
On 02/11/2016 12:38, Ferruh Yigit wrote:
> Hi Mauricio,
>
> On 11/1/2016 7:55 PM, Mauricio Vasquez B wrote:
>> Coverity detected this as an issue because internals->data will never be NULL,
>> then the check is not necessary.
>>
>> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
>> Coverity issue: 137873
>>
>> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
>> ---
>> drivers/net/ring/rte_eth_ring.c | 20 +++++++++-----------
>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
>> index 6d2a8c1..5ca00ed 100644
>> --- a/drivers/net/ring/rte_eth_ring.c
>> +++ b/drivers/net/ring/rte_eth_ring.c
>> @@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
>>
>> eth_dev_stop(eth_dev);
>>
>> - if (eth_dev->data) {
>> - internals = eth_dev->data->dev_private;
>> - if (internals->action == DEV_CREATE) {
>> - /*
>> - * it is only necessary to delete the rings in rx_queues because
>> - * they are the same used in tx_queues
>> - */
>> - for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>> - r = eth_dev->data->rx_queues[i];
>> - rte_ring_free(r->rng);
>> - }
>> + internals = eth_dev->data->dev_private;
>> + if (internals->action == DEV_CREATE) {
>> + /*
>> + * it is only necessary to delete the rings in rx_queues because
>> + * they are the same used in tx_queues
>> + */
>> + for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>> + r = eth_dev->data->rx_queues[i];
>> + rte_ring_free(r->rng);
>> }
>>
>> rte_free(eth_dev->data->rx_queues);
>
> This patch not only removes the NULL check but also changes the logic.
> after patch rx_queues, tx_queues and dev_private only freed if action is
> DEV_CREATE which is wrong.
>
>>
>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-11-02 12:57 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102114837.GC40328@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Nov 02, 2016 at 11:48:37AM +0000, Bruce Richardson wrote:
> On Wed, Nov 02, 2016 at 01:36:34PM +0530, Jerin Jacob wrote:
> > On Fri, Oct 28, 2016 at 01:48:57PM +0000, Van Haaren, Harry wrote:
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > Sent: Tuesday, October 25, 2016 6:49 PM
> > > <snip>
> > > >
> > > > Hi Community,
> > > >
> > > > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > > > Let me know, if anyone else interested in contributing to the definition of eventdev?
> > > >
> > > > If there are no major issues in proposed spec, then Cavium would like work on
> > > > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > > > an associated HW driver.(Requested minor changes of v2 will be addressed
> > > > in next version).
> > >
> > >
> > > Hi All,
> > >
> > > I've been looking at the eventdev API from a use-case point of view, and I'm unclear on a how the API caters for two uses. I have simplified these as much as possible, think of them as a theoretical unit-test for the API :)
> > >
> > >
> > > Fragmentation:
> > > 1. Dequeue 8 packets
> > > 2. Process 2 packets
> > > 3. Processing 3rd, this packet needs fragmentation into two packets
> > > 4. Process remaining 5 packets as normal
> > >
> > > What function calls does the application make to achieve this?
> > > In particular, I'm referring to how can the scheduler know that the 3rd packet is the one being fragmented, and how to keep packet order valid.
> > >
> >
> > OK. I will try to share my views on IP fragmentation on event _HW_
> > models(at least on Cavium HW) then we can see, how we can converge.
> >
> > First, The fragmentation specific logic should be decoupled from the event
> > model as it specific to packet and L3 layer(Not specific to generic event)
> >
> I would view fragmentation as just one example of a workload like this,
> multicast and broadcast may be two other cases. Yes, they all apply to
> packet, but the general feature support is just how to provide support
> for one event generating multiple further events which should be linked
> together for reordering. [I think this only really applies in the
AFIAK, There two different schemes to "maintain ordering", the first one
is based "reordering buffers" i.e as a list data structure used to hold the
event first and then when it comes correcting the order(ORDERED->ATOMIC),
correct the order based on the previous "reordering buffers".
But some HW implementation use "port" state based reordering scheme
(i.e no external reorder buffer to keep track the order).
So I think, To have portable application workflow, the use case where multiple
event generated based on one event, generated events needs to store in the parent event
and in the downstream, process them as required. like fragmentation example in
http://dpdk.org/ml/archives/dev/2016-November/049707.html
The above scheme should OK in your implementation. Right?
> reordered case - which leads to another question: in your experience
> do you see other event types other than packet being handled in a
> "reordered" manner?]
We use both timer events and crypto completion events etc in ORDERED
type. But not like, one event creates N event scheme on those.
>
> /Bruce
>
^ permalink raw reply
* Re: [PATCH v2] doc/guides: add more info about VT-d/iommu settings
From: Kusztal, ArkadiuszX @ 2016-11-02 13:00 UTC (permalink / raw)
To: Trahe, Fiona, dev@dpdk.org
In-Reply-To: <1477502611-3097-1-git-send-email-fiona.trahe@intel.com>
> -----Original Message-----
> From: Trahe, Fiona
> Sent: Wednesday, October 26, 2016 6:24 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Griffin, John <john.griffin@intel.com>
> Subject: [PATCH v2] doc/guides: add more info about VT-d/iommu settings
>
> Add more information about VT-d/iommu settings for QAT PMD.
> Remove limitation indicating QAT driver is not performance tuned.
>
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> ---
>
> v2:
> clarified commit message
>
>
> doc/guides/cryptodevs/qat.rst | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index 70bc2b1..bbe0b12 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
>
> --
> 2.5.0
Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-11-02 13:09 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102113551.GA40328@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Nov 02, 2016 at 11:35:51AM +0000, Bruce Richardson wrote:
> On Wed, Nov 02, 2016 at 04:55:22PM +0530, Jerin Jacob wrote:
> > On Fri, Oct 28, 2016 at 02:36:48PM +0530, Jerin Jacob wrote:
> > > On Fri, Oct 28, 2016 at 09:36:46AM +0100, Bruce Richardson wrote:
> > > > On Fri, Oct 28, 2016 at 08:31:41AM +0530, Jerin Jacob wrote:
> > > > > On Wed, Oct 26, 2016 at 01:54:14PM +0100, Bruce Richardson wrote:
> > > > > > On Wed, Oct 26, 2016 at 05:54:17PM +0530, Jerin Jacob wrote:
> > > > > How about making default as "mixed" and let application configures what
> > > > > is not required?. That way application responsibility is clear.
> > > > > something similar to ETH_TXQ_FLAGS_NOMULTSEGS, ETH_TXQ_FLAGS_NOREFCOUNT
> > > > > with default.
> > > > >
> > > > I suppose it could work, but why bother doing that? If an app knows it's
> > > > only going to use one traffic type, why not let it just state what it
> > > > will do rather than try to specify what it won't do. If mixed is needed,
> > >
> > > My thought was more inline with ethdev spec, like, ref-count is default,
> > > if application need exception then set ETH_TXQ_FLAGS_NOREFCOUNT. But it is OK, if
> > > you need other way.
> > >
> > > > then it's easy enough to specify - and we can make it the zero/default
> > > > value too.
> > >
> > > OK. Then we will make MIX as zero/default and add "allowed_event_types" in
> > > event queue config.
> > >
> >
> > Bruce,
> >
> > I have tried to make it as "allowed_event_types" in event queue config.
> > However, rte_event_queue_default_conf_get() can also take NULL for default
> > configuration. So I think, It makes sense to go with negation approach
> > like ethdev to define the default to avoid confusion on the default. So
> > I am thinking like below now,
> >
> > ➜ [master][libeventdev] $ git diff
> > diff --git a/rte_eventdev.h b/rte_eventdev.h
> > index cf22b0e..cac4642 100644
> > --- a/rte_eventdev.h
> > +++ b/rte_eventdev.h
> > @@ -429,6 +429,12 @@ rte_event_dev_configure(uint8_t dev_id, struct
> > rte_event_dev_config *config);
> > *
> > * \see rte_event_port_setup(), rte_event_port_link()
> > */
> > +#define RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE (1ULL << 1)
> > +/**< Skip configuring atomic schedule type resources */
> > +#define RTE_EVENT_QUEUE_CFG_NOORDERED_TYPE (1ULL << 2)
> > +/**< Skip configuring ordered schedule type resources */
> > +#define RTE_EVENT_QUEUE_CFG_NOPARALLEL_TYPE (1ULL << 3)
> > +/**< Skip configuring parallel schedule type resources */
> >
> > /** Event queue configuration structure */
> > struct rte_event_queue_conf {
> >
> > Thoughts?
> >
>
> I'm ok with the default as being all types, in the case where NULL is
> specified for the parameter. It does make the most sense.
Yes. That case I need to explicitly mention in the documentation about what
is default case. With RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE scheme it quite
understood what is default. Not adding up? :-)
>
> However, for the cases where the user does specify what they want, I
> think it does make more sense, and is easier on the user for things to
> be specified in a positive, rather than negative sense. For a user who
> wants to just use atomic events, having to specify that as "not-reordered
> and not-unordered" just isn't as clear! :-)
>
> /Bruce
>
^ permalink raw reply
* Re: [PATCH v2] net/ring: remove unnecessary NULL check
From: Ferruh Yigit @ 2016-11-02 13:15 UTC (permalink / raw)
To: Fulvio Risso, Mauricio Vasquez B, bruce.richardson; +Cc: dev
In-Reply-To: <7a81d33e-4b91-7dca-e6e4-f009d295bebf@polito.it>
On 11/2/2016 12:49 PM, Fulvio Risso wrote:
> Dear Ferruh,
> Maybe I'm wrong, but I cannot see your point.
> The code is absolutely the same, only the following line
>
> if (eth_dev->data) {
>
> is actually removed.
Please double check the condition "rx_queues" freed:
before the patch:
==========
if (eth_dev->data) {
internals = eth_dev->data->dev_private;
if (internals->action == DEV_CREATE) {
/*
* it is only necessary to delete the rings in rx_queues because
* they are the same used in tx_queues
*/
for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
r = eth_dev->data->rx_queues[i];
rte_ring_free(r->rng);
}
}
rte_free(eth_dev->data->rx_queues);
rte_free(eth_dev->data->tx_queues);
rte_free(eth_dev->data->dev_private);
}
==========
After the patch:
==========
internals = eth_dev->data->dev_private;
if (internals->action == DEV_CREATE) {
/*
* it is only necessary to delete the rings in rx_queues because
* they are the same used in tx_queues
*/
for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
r = eth_dev->data->rx_queues[i];
rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
rte_free(eth_dev->data->tx_queues);
rte_free(eth_dev->data->dev_private);
}
==========
Thanks,
ferruh
^ permalink raw reply
* [PATCH v3] net/ring: remove unnecessary NULL check
From: Mauricio Vasquez B @ 2016-11-02 13:46 UTC (permalink / raw)
To: bruce.richardson; +Cc: dev, ferruh.yigit
In-Reply-To: <1478030140-7127-1-git-send-email-mauricio.vasquez@polito.it>
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
---
drivers/net/ring/rte_eth_ring.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..c1767c4 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,24 +599,22 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
- * it is only necessary to delete the rings in rx_queues because
- * they are the same used in tx_queues
- */
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+ * it is only necessary to delete the rings in rx_queues because
+ * they are the same used in tx_queues
+ */
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
-
- rte_free(eth_dev->data->rx_queues);
- rte_free(eth_dev->data->tx_queues);
- rte_free(eth_dev->data->dev_private);
}
+ rte_free(eth_dev->data->rx_queues);
+ rte_free(eth_dev->data->tx_queues);
+ rte_free(eth_dev->data->dev_private);
+
rte_free(eth_dev->data);
rte_eth_dev_release_port(eth_dev);
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] update mlx5 release note and guide
From: Nelio Laranjeiro @ 2016-11-02 13:46 UTC (permalink / raw)
To: dev
Nelio Laranjeiro (2):
doc: update mlx5 dependencies
doc: add mlx5 release notes
doc/guides/nics/mlx5.rst | 8 +-
doc/guides/rel_notes/release_16_11.rst | 136 ++++++++++++++++++++++++++-------
2 files changed, 114 insertions(+), 30 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] doc: update mlx5 dependencies
From: Nelio Laranjeiro @ 2016-11-02 13:46 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1478094292.git.nelio.laranjeiro@6wind.com>
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/nics/mlx5.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 0d1fabb..98d1341 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -241,12 +241,12 @@ DPDK and must be installed separately:
Currently supported by DPDK:
-- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**.
+- Mellanox OFED **3.4-1.0.0.0**.
-- Minimum firmware version:
+- firmware version:
- - ConnectX-4: **12.16.1006**
- - ConnectX-4 Lx: **14.16.1006**
+ - ConnectX-4: **12.17.1010**
+ - ConnectX-4 Lx: **14.17.1010**
Getting Mellanox OFED
~~~~~~~~~~~~~~~~~~~~~
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] doc: add mlx5 release notes
From: Nelio Laranjeiro @ 2016-11-02 13:46 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1478094292.git.nelio.laranjeiro@6wind.com>
Add list of tested and validated NICs too.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
doc/guides/rel_notes/release_16_11.rst | 136 ++++++++++++++++++++++++++-------
1 file changed, 110 insertions(+), 26 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index aa0c09a..7447195 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -131,6 +131,13 @@ New Features
The GCC 4.9 ``-march`` option supports the Intel processor code names.
The config option ``RTE_MACHINE`` can be used to pass code names to the compiler as ``-march`` flag.
+* **Updated the mlx5 driver.**
+
+ The following changes were made to mlx5:
+
+ * Add support for RSS hash result
+ * Several performance improvements
+ * Several bug fixes
Resolved Issues
---------------
@@ -265,47 +272,124 @@ The libraries prepended with a plus sign were incremented in this version.
Tested Platforms
----------------
-.. This section should contain a list of platforms that were tested with this release.
+#. Intel(R) Server board S2600WTT
- The format is:
+ - Processor: Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
- #. Platform name.
+#. Intel(R) Server
- * Platform details.
- * Platform details.
+ - Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- This section is a comment. Make sure to start the actual text at the margin.
+#. Intel(R) Server
+
+ - Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
+#. IBM(R) Power8(R)
+
+ - Machine type-model: 8247-22L
+ - Firmware FW810.21 (SV810_108)
+ - Processor: POWER8E (raw), AltiVec supported
Tested NICs
-----------
-.. This section should contain a list of NICs that were tested with this release.
+#. Mellanox(R) ConnectX(R)-4 10G MCX4111A-XCAT (1x10G)
- The format is:
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
- #. NIC name.
+#. Mellanox(R) ConnectX(R)-4 10G MCX4121A-XCAT (2x10G)
- * NIC details.
- * NIC details.
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
- This section is a comment. Make sure to start the actual text at the margin.
+#. Mellanox(R) ConnectX(R)-4 25G MCX4111A-ACAT (1x25G)
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
-Tested OSes
------------
+#. Mellanox(R) ConnectX(R)-4 25G MCX4121A-ACAT (2x25G)
-.. This section should contain a list of OSes that were tested with this release.
- The format is as follows, in alphabetical order:
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
- * CentOS 7.0
- * Fedora 23
- * Fedora 24
- * FreeBSD 10.3
- * Red Hat Enterprise Linux 7.2
- * SUSE Enterprise Linux 12
- * Ubuntu 15.10
- * Ubuntu 16.04 LTS
- * Wind River Linux 8
+#. Mellanox(R) ConnectX(R)-4 40G MCX4131A-BCAT/MCX413A-BCAT (1x40G)
- This section is a comment. Make sure to start the actual text at the margin.
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 40G MCX415A-BCAT (1x40G)
+
+ * Host interface: PCI Express 3.0 x16
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 50G MCX4131A-GCAT/MCX413A-GCAT (1x50G)
+
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 50G MCX414A-BCAT (2x50G)
+
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 50G MCX415A-GCAT/MCX416A-BCAT/MCX416A-GCAT (2x50G)
+
+ * Host interface: PCI Express 3.0 x16
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 50G MCX415A-CCAT (1x100G)
+
+ * Host interface: PCI Express 3.0 x16
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 100G MCX416A-CCAT (2x100G)
+
+ * Host interface: PCI Express 3.0 x16
+ * Device ID: 15b3:1013
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 12.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 Lx 10G MCX4121A-XCAT (2x10G)
+
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1015
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 14.17.1010
+
+#. Mellanox(R) ConnectX(R)-4 Lx 25G MCX4121A-ACAT (2x25G)
+
+ * Host interface: PCI Express 3.0 x8
+ * Device ID: 15b3:1015
+ * MLNX_OFED: 3.4-1.0.0.0
+ * Firmware version: 14.17.1010
+
+Tested OSes
+-----------
+
+ * Red Hat Enterprise Linux Server release 6.7 (Santiago)
+ * Red Hat Enterprise Linux Server release 7.0 (Maipo)
+ * Red Hat Enterprise Linux Server release 7.2 (Maipo)
+ * Wind River Linux 6.0.0.26
+ * Ubuntu 14.04
+ * Ubuntu 15.04
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] net/ring: remove unnecessary NULL check
From: Mauricio Vasquez @ 2016-11-02 13:50 UTC (permalink / raw)
To: Ferruh Yigit, Fulvio Risso, bruce.richardson; +Cc: dev
In-Reply-To: <200cca44-01e1-084b-ce86-0e47ca943f9a@intel.com>
Dear Ferruh,
You are right, I messed up the brackets.
I already sent v3.
Thanks,
Mauricio.
On 11/02/2016 08:15 AM, Ferruh Yigit wrote:
> On 11/2/2016 12:49 PM, Fulvio Risso wrote:
>> Dear Ferruh,
>> Maybe I'm wrong, but I cannot see your point.
>> The code is absolutely the same, only the following line
>>
>> if (eth_dev->data) {
>>
>> is actually removed.
> Please double check the condition "rx_queues" freed:
>
> before the patch:
> ==========
> if (eth_dev->data) {
> internals = eth_dev->data->dev_private;
> if (internals->action == DEV_CREATE) {
> /*
> * it is only necessary to delete the rings in rx_queues because
> * they are the same used in tx_queues
> */
> for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> r = eth_dev->data->rx_queues[i];
> rte_ring_free(r->rng);
> }
> }
>
> rte_free(eth_dev->data->rx_queues);
> rte_free(eth_dev->data->tx_queues);
> rte_free(eth_dev->data->dev_private);
> }
> ==========
>
>
> After the patch:
> ==========
> internals = eth_dev->data->dev_private;
> if (internals->action == DEV_CREATE) {
> /*
> * it is only necessary to delete the rings in rx_queues because
> * they are the same used in tx_queues
> */
> for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
> r = eth_dev->data->rx_queues[i];
> rte_ring_free(r->rng);
> }
>
> rte_free(eth_dev->data->rx_queues);
> rte_free(eth_dev->data->tx_queues);
> rte_free(eth_dev->data->dev_private);
> }
> ==========
>
>
> Thanks,
> ferruh
>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Bruce Richardson @ 2016-11-02 13:56 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102130925.GC2564@localhost.localdomain>
On Wed, Nov 02, 2016 at 06:39:27PM +0530, Jerin Jacob wrote:
> On Wed, Nov 02, 2016 at 11:35:51AM +0000, Bruce Richardson wrote:
> > On Wed, Nov 02, 2016 at 04:55:22PM +0530, Jerin Jacob wrote:
> > > On Fri, Oct 28, 2016 at 02:36:48PM +0530, Jerin Jacob wrote:
> > > > On Fri, Oct 28, 2016 at 09:36:46AM +0100, Bruce Richardson wrote:
> > > > > On Fri, Oct 28, 2016 at 08:31:41AM +0530, Jerin Jacob wrote:
> > > > > > On Wed, Oct 26, 2016 at 01:54:14PM +0100, Bruce Richardson wrote:
> > > > > > > On Wed, Oct 26, 2016 at 05:54:17PM +0530, Jerin Jacob wrote:
> > > > > > How about making default as "mixed" and let application configures what
> > > > > > is not required?. That way application responsibility is clear.
> > > > > > something similar to ETH_TXQ_FLAGS_NOMULTSEGS, ETH_TXQ_FLAGS_NOREFCOUNT
> > > > > > with default.
> > > > > >
> > > > > I suppose it could work, but why bother doing that? If an app knows it's
> > > > > only going to use one traffic type, why not let it just state what it
> > > > > will do rather than try to specify what it won't do. If mixed is needed,
> > > >
> > > > My thought was more inline with ethdev spec, like, ref-count is default,
> > > > if application need exception then set ETH_TXQ_FLAGS_NOREFCOUNT. But it is OK, if
> > > > you need other way.
> > > >
> > > > > then it's easy enough to specify - and we can make it the zero/default
> > > > > value too.
> > > >
> > > > OK. Then we will make MIX as zero/default and add "allowed_event_types" in
> > > > event queue config.
> > > >
> > >
> > > Bruce,
> > >
> > > I have tried to make it as "allowed_event_types" in event queue config.
> > > However, rte_event_queue_default_conf_get() can also take NULL for default
> > > configuration. So I think, It makes sense to go with negation approach
> > > like ethdev to define the default to avoid confusion on the default. So
> > > I am thinking like below now,
> > >
> > > ➜ [master][libeventdev] $ git diff
> > > diff --git a/rte_eventdev.h b/rte_eventdev.h
> > > index cf22b0e..cac4642 100644
> > > --- a/rte_eventdev.h
> > > +++ b/rte_eventdev.h
> > > @@ -429,6 +429,12 @@ rte_event_dev_configure(uint8_t dev_id, struct
> > > rte_event_dev_config *config);
> > > *
> > > * \see rte_event_port_setup(), rte_event_port_link()
> > > */
> > > +#define RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE (1ULL << 1)
> > > +/**< Skip configuring atomic schedule type resources */
> > > +#define RTE_EVENT_QUEUE_CFG_NOORDERED_TYPE (1ULL << 2)
> > > +/**< Skip configuring ordered schedule type resources */
> > > +#define RTE_EVENT_QUEUE_CFG_NOPARALLEL_TYPE (1ULL << 3)
> > > +/**< Skip configuring parallel schedule type resources */
> > >
> > > /** Event queue configuration structure */
> > > struct rte_event_queue_conf {
> > >
> > > Thoughts?
> > >
> >
> > I'm ok with the default as being all types, in the case where NULL is
> > specified for the parameter. It does make the most sense.
>
> Yes. That case I need to explicitly mention in the documentation about what
> is default case. With RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE scheme it quite
> understood what is default. Not adding up? :-)
>
Would below not work? DEFAULT explicitly stated, and can be commented to
say all types allowed.
#define RTE_EVENT_QUEUE_CFG_DEFAULT 0
#define RTE_EVENT_QUEUE_CFG_ALL_TYPES RTE_EVENT_QUEUE_CFG_DEFAULT
#define RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY (1<<0)
#define RTE_EVENT_QUEUE_CFG_ORDERED_ONLY (1<<1)
....
/Bruce
^ permalink raw reply
* Re: [PATCH v3] net/ring: remove unnecessary NULL check
From: Ferruh Yigit @ 2016-11-02 14:05 UTC (permalink / raw)
To: Mauricio Vasquez B, bruce.richardson; +Cc: dev
In-Reply-To: <1478094369-3943-1-git-send-email-mauricio.vasquez@polito.it>
On 11/2/2016 1:46 PM, Mauricio Vasquez B wrote:
> Coverity detected this as an issue because internals->data will never be NULL,
> then the check is not necessary.
>
> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
> Coverity issue: 137873
>
> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
> ---
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH] app/test: fix wrong pointer values in crypto perftest
From: Trahe, Fiona @ 2016-11-02 14:45 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, dev@dpdk.org
In-Reply-To: <1477654629-22181-1-git-send-email-arkadiuszx.kusztal@intel.com>
> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Friday, October 28, 2016 12:37 PM
> To: dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Griffin, John <john.griffin@intel.com>;
> Jain, Deepak K <deepak.k.jain@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH] app/test: fix wrong pointer values in crypto perftest
>
> This commit fixes problem with device hanging because of
> wrong pointer values in snow3g performance test
>
> Fixes: 97fe6461c7cb ("app/test: add SNOW 3G performance test")
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-11-02 14:54 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage
In-Reply-To: <20161102135627.GA42352@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Nov 02, 2016 at 01:56:27PM +0000, Bruce Richardson wrote:
> On Wed, Nov 02, 2016 at 06:39:27PM +0530, Jerin Jacob wrote:
> > On Wed, Nov 02, 2016 at 11:35:51AM +0000, Bruce Richardson wrote:
> > > On Wed, Nov 02, 2016 at 04:55:22PM +0530, Jerin Jacob wrote:
> > > > On Fri, Oct 28, 2016 at 02:36:48PM +0530, Jerin Jacob wrote:
> > > > > On Fri, Oct 28, 2016 at 09:36:46AM +0100, Bruce Richardson wrote:
> > > > > > On Fri, Oct 28, 2016 at 08:31:41AM +0530, Jerin Jacob wrote:
> > > > > > > On Wed, Oct 26, 2016 at 01:54:14PM +0100, Bruce Richardson wrote:
> > > > > > > > On Wed, Oct 26, 2016 at 05:54:17PM +0530, Jerin Jacob wrote:
> > > > > > > How about making default as "mixed" and let application configures what
> > > > > > > is not required?. That way application responsibility is clear.
> > > > > > > something similar to ETH_TXQ_FLAGS_NOMULTSEGS, ETH_TXQ_FLAGS_NOREFCOUNT
> > > > > > > with default.
> > > > > > >
> > > > > > I suppose it could work, but why bother doing that? If an app knows it's
> > > > > > only going to use one traffic type, why not let it just state what it
> > > > > > will do rather than try to specify what it won't do. If mixed is needed,
> > > > >
> > > > > My thought was more inline with ethdev spec, like, ref-count is default,
> > > > > if application need exception then set ETH_TXQ_FLAGS_NOREFCOUNT. But it is OK, if
> > > > > you need other way.
> > > > >
> > > > > > then it's easy enough to specify - and we can make it the zero/default
> > > > > > value too.
> > > > >
> > > > > OK. Then we will make MIX as zero/default and add "allowed_event_types" in
> > > > > event queue config.
> > > > >
> > > >
> > > > Bruce,
> > > >
> > > > I have tried to make it as "allowed_event_types" in event queue config.
> > > > However, rte_event_queue_default_conf_get() can also take NULL for default
> > > > configuration. So I think, It makes sense to go with negation approach
> > > > like ethdev to define the default to avoid confusion on the default. So
> > > > I am thinking like below now,
> > > >
> > > > ➜ [master][libeventdev] $ git diff
> > > > diff --git a/rte_eventdev.h b/rte_eventdev.h
> > > > index cf22b0e..cac4642 100644
> > > > --- a/rte_eventdev.h
> > > > +++ b/rte_eventdev.h
> > > > @@ -429,6 +429,12 @@ rte_event_dev_configure(uint8_t dev_id, struct
> > > > rte_event_dev_config *config);
> > > > *
> > > > * \see rte_event_port_setup(), rte_event_port_link()
> > > > */
> > > > +#define RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE (1ULL << 1)
> > > > +/**< Skip configuring atomic schedule type resources */
> > > > +#define RTE_EVENT_QUEUE_CFG_NOORDERED_TYPE (1ULL << 2)
> > > > +/**< Skip configuring ordered schedule type resources */
> > > > +#define RTE_EVENT_QUEUE_CFG_NOPARALLEL_TYPE (1ULL << 3)
> > > > +/**< Skip configuring parallel schedule type resources */
> > > >
> > > > /** Event queue configuration structure */
> > > > struct rte_event_queue_conf {
> > > >
> > > > Thoughts?
> > > >
> > >
> > > I'm ok with the default as being all types, in the case where NULL is
> > > specified for the parameter. It does make the most sense.
> >
> > Yes. That case I need to explicitly mention in the documentation about what
> > is default case. With RTE_EVENT_QUEUE_CFG_NOATOMIC_TYPE scheme it quite
> > understood what is default. Not adding up? :-)
> >
>
> Would below not work? DEFAULT explicitly stated, and can be commented to
> say all types allowed.
All I was trying to avoid explicitly stating the default state. Not worth
to have back and forth on slow path configuration, I will keep it as
positive logic as you suggested :-) and inspired from PKT_TX_L4_MASK
#define RTE_EVENT_QUEUE_CFG_TYPE_MASK (3ULL << 0)
#define RTE_EVENT_QUEUE_CFG_ALL_TYPES (0ULL << 0) /**< Enable all types */
#define RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY (1ULL << 0)
#define RTE_EVENT_QUEUE_CFG_ORDERED_ONLY (2ULL << 0)
#define RTE_EVENT_QUEUE_CFG_PARALLEL_ONLY (3ULL << 0)
#define RTE_EVENT_QUEUE_CFG_SINGLE_CONSUMER (1ULL << 2)
>
> #define RTE_EVENT_QUEUE_CFG_DEFAULT 0
> #define RTE_EVENT_QUEUE_CFG_ALL_TYPES RTE_EVENT_QUEUE_CFG_DEFAULT
> #define RTE_EVENT_QUEUE_CFG_ATOMIC_ONLY (1<<0)
> #define RTE_EVENT_QUEUE_CFG_ORDERED_ONLY (1<<1)
> ....
>
> /Bruce
^ permalink raw reply
* Re: [PATCH] doc: announce ABI changes in filtering support
From: Stroe, Laura @ 2016-11-02 15:12 UTC (permalink / raw)
To: dev@dpdk.org
In-Reply-To: <1474629771-21574-1-git-send-email-laura.stroe@intel.com>
Self-Nack.
After an internal review of ABI breakage announcements we found a way of achieving this with an ABI change.
-----Original Message-----
From: Stroe, Laura
Sent: Friday, September 23, 2016 12:23 PM
To: dev@dpdk.org
Cc: Stroe, Laura <laura.stroe@intel.com>
Subject: [PATCH] doc: announce ABI changes in filtering support
From: Laura Stroe <laura.stroe@intel.com>
This patch adds a notice that the ABI for filter types functionality will be enhanced in the 17.02 release with new operation available to manipulate the tunnel filters:
replace filter types.
Signed-off-by: Laura Stroe <laura.stroe@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1a3831f..1cd1d2c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -57,3 +57,12 @@ Deprecation Notices
* API will change for ``rte_port_source_params`` and ``rte_port_sink_params``
structures. The member ``file_name`` data type will be changed from
``char *`` to ``const char *``. This change targets release 16.11.
+
+* In 17.02 ABI changes are planned: the ``rte_filter_op `` enum will be
+extended
+ with a new member RTE_ETH_FILTER_REPLACE in order to facilitate
+ the new operation - replacing the tunnel filters,
+ the ``rte_eth_tunnel_filter_conf`` structure will be extended with a
+new field
+ ``filter_type_replace`` handling the bitmask combination of the
+filter types
+ defined by the values ETH_TUNNEL_FILTER_XX,
+ define new values for Outer VLAN and Outer Ethertype filters
+ ETH_TUNNEL_FILTER_OVLAN and ETH_TUNNEL_FILTER_OETH.
--
2.5.5
^ permalink raw reply related
* Re: dpdk16.11 RC2 package ipv4 reassembly example can't work
From: Adrien Mazarguil @ 2016-11-02 15:21 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093934068B@shsmsx102.ccr.corp.intel.com>
Hi all,
On Wed, Nov 02, 2016 at 08:39:31AM +0000, Lu, Wenzhuo wrote:
> Correct the typo of receiver.
>
> Hi Adrien,
> The change from struct ip_frag_pkt pkt[0] to struct ip_frag_pkt pkt[] will make IP reassembly not working. I think this is not the root cause. Maybe Konstantin can give us some idea.
> But I notice one thing, you change some from [0] to [], but others just add '__extension__'. I believe if you add '__extension__' for struct ip_frag_pkt pkt[0], we'll not hit this issue. Just curious why you use 2 ways to resolve the same problem.
I've used the __extension__ method whenever the C99 syntax could not work
due to invalid usage in the code, e.g. a flexible array cannot be the only
member of a struct, you cannot make arrays out of structures that contain
such fields, while there is no such constraint with the GNU syntax.
For example see __extension__ uint8_t action_data[0] in struct
rte_pipeline_table_entry. The C99 could not be used because of
test_table_acl.c:
struct rte_pipeline_table_entry entries[5];
If replacing ip_frag_pkt[] with __extension__ ip_frag_pkt pkt[0] in
rte_ip_frag.h solves the issue, either some code is breaking some constraint
somewhere or this change broke the ABI (unlikely considering a simple
recompilation should have taken care of the issue). I did not notice any
change in sizeof(struct rte_ip_frag_tbl) nor offsetof(struct
rte_ip_frag_tbl, pkt) on my setup, perhaps the compilation flags used in
your test affect them somehow.
Can you confirm whether only reverting this particular field solves the
issue?
> From: Xu, HuilongX
> Sent: Wednesday, November 2, 2016 4:29 PM
> To: drien.mazarguil@6wind.com
> Cc: Ananyev, Konstantin; Liu, Yu Y; Chen, WeichunX; Lu, Wenzhuo; Xu, HuilongX
> Subject: dpdk16.11 RC2 package ipv4 reassembly example can't work
>
> Hi mazarguil,
> I find ip reassembly example can't work with dpdk16.11 rc2 package.
> But when I reset dpdk code before 347a1e037fd323e6c2af55d17f7f0dc4bfe1d479, it works ok.
> Could you have time to check this issue, thanks a lot.
> Unzip password: intel123
>
> Test detail info:
>
> os&kernel:4.2.3-300.fc23.x86_64
> gcc version:5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)
> NIC:03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T [8086:15ad] and
> 84:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
> package: dpdk16.11.rc2.tar.gz
> test steps:
> 1. build and install dpdk
> 2. build ip_reassembly example
> 3. run ip_reassembly
> ./examples/ip_reassembly/build/ip_reassembly -c 0x2 -n 4 - -p 0x1 --maxflows=1024 --flowttl=10s
> 4. set tester port mtu
> ip link set mtu 9000 dev ens160f1
> 5. setup scapy on tester and send packet
> scapy
> pcap = rdpcap("file.pcap")
> sendp(pcap, iface="ens160f1")
> 6. sniff packet on tester and check packet
> test result:
> dpdk16.04 reassembly packet successful but dpdk16.11 reassembly pack failed.
>
> comments:
> file.pcap: send packets pcap file
> tcpdump_16.04_reassembly_successful.pcap: sniff packets by tcpdump on 16.04.
> tcpdump_reset_code_reassembly_failed.pcap: sniff packets by tcpdump on 16.11
> reset_code_reassembly_successful_.jpg: reassembly a packets successful detail info
> dpdk16.11_reassembly_failed.jpg: reassembly a packets failed detail info
>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Possible memory corruption due to incorrect DMA shutdown
From: George Prekas @ 2016-11-02 15:43 UTC (permalink / raw)
To: dev
I have posted the following messages on users@dpdk.organd it seems that
it was the wrong mailing list:
http://dpdk.org/ml/archives/users/2016-March/000340.html
http://dpdk.org/ml/archives/users/2016-September/001026.html
I also include the message here for convenience:
I can consistently reproduce this behavior following these steps:
On host A do:
$ sudo modprobe uio
$ sudo insmod ./build/kmod/igb_uio.ko
$ sudo python ./tools/dpdk_nic_bind.py --bind=igb_uio 0000:42:00.1
$ sudo ./build/app/testpmd -- --forward-mode=icmpecho
From host B (which is on the same local network), do an arping to an
arbitrary IP address C.C.C.C (that is in the same network and it doesn't
belong to another host). DPDK will respond to any IP address. All you
want is to populate host B's ARP cache. Then terminate DPDK and run the
following Python program on host B:
import sys
import socket
A=sys.argv[3] * int(sys.argv[2])
for i in xrange(10000):
sock = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
sock.sendto(A, (sys.argv[1], 1))
as:
$ python go.py C.C.C.C 28 prekageo_was_here_
Then go back to host A and use the physical memory grep tool that you
can find here https://github.com/prekageo/allmemscan
$ make
$ sudo insmod allmem.ko
$ sudo ./allmemscan 28 prekageo_was_here
Optionally:
$ sudo dd if=/dev/allmem bs=4K skip=PAGE count=1 | hexdump -C | less
On 11/03/2016 19:41, George Prekas wrote:
> Hi. I've been using DPDK for a research project
> (https://www.usenix.org/conference/osdi14/technical-sessions/presentation/belay)
> for over 2 years and I'd like to report a behavior that puzzles me
> using DPDK.
>
> The behavior leads to memory corruption and is caused by the incorrect
> shutdown of DMA. I can reproduce it after executing the following steps:
>
> $ sudo modprobe uio
> $ sudo insmod ./build/kmod/igb_uio.ko
> $ sudo python ./tools/dpdk_nic_bind.py --bind=igb_uio 0000:42:00.1
> $ sudo ./build/app/testpmd -- --forward-mode=icmpecho
>
> Then I terminate the DPDK program (after populating the ARP cache of
> another host on the local network). After this, I can send UDP packets
> to the host and can observe their payload in host memory. Clearly,
> network packets are arriving to the network card and are written to
> RAM after DPDK has finished executing.
>
> Am I doing something wrong? Is this behavior expected?
>
> Regards,
> George
>
^ permalink raw reply
* Re: [RFC]Generic flow filtering API Sample Application
From: Adrien Mazarguil @ 2016-11-02 15:47 UTC (permalink / raw)
To: Zhao1, Wei; +Cc: dev@dpdk.org
In-Reply-To: <A2573D2ACFCADC41BB3BE09C6DE313CA01FE9D0F@PGSMSX103.gar.corp.intel.com>
Hi Wei,
On Wed, Nov 02, 2016 at 05:27:50AM +0000, Zhao1, Wei wrote:
> Hi All,
> Now we are planning for an sample application for Generic flow
> filtering API feature, and I have finished the RFC for this example app.
> Now Adrien Mazarguil has send v2 version of Generic flow
> filtering API, this sample application RFC is based on that.
>
> Thank you.
Thanks for your RFC, sorry for the late notice that I've been essentially
working on a similar implementation in testpmd in order to validate the API
before sending v1, which I concede is taking way longer than expected.
I have yet to submit my patches however this should happen soon, if you
haven't started working on your own implementation yet, please wait until my
implementation gets rejected to avoid any more duplicated effort in the
meantime.
BTW, I find a lot of similarities between our respective command-line
handling approaches, which is great! We're going in the same direction.
> Generic flow filtering API Sample Application
> ============================================
>
> The application is a simple example of generic flow filtering API using the DPDK.
> The application performs flow director/filtering/classification in packet processing.
>
> Overview
> --------
>
> The application demonstrates the use of generic flow director/filtering/classification API
> in the DPDK to implement packet forwarding.And this document focus on the guide line of writing rules configuration
> files and prompt commands usage. It also supply the definition of the available EAL options arguments which is useful
> in DPDK packet forwarding processing.
>
>
> Compiling the Application
> -------------------------
>
> To compile the application:
>
> #. Go to the sample application directory:
>
> .. code-block:: console
>
> export RTE_SDK=/path/to/rte_sdk
> cd ${RTE_SDK}/examples/gen_filter
>
> #. Set the target (a default target is used if not specified). For example:
>
> .. code-block:: console
>
> export RTE_TARGET=x86_64-native-linuxapp-gcc
>
> See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
>
> #. Build the application:
>
> .. code-block:: console
>
> make
>
> Running the Application
> -----------------------
> The application has a number of EAL options::
>
> ./gen_filter [EAL options] -- <APP PARAMS>
>
> EAL options:
> * -c
> Codemask, set the hexadecimal bitmask of the cores to run on.
>
> * -n
> Num, set the number of memory channels to use.
>
> APP PARAMS:
> The following are the application options parameters, they must be separated
> from the EAL options with a "--" separator.
>
> * -i
> Interactive, run this app in interactive mode. In this mode, the app starts with a prompt that can
> be used to start and stop forwarding, then manage generic filters rule configure in the application,
> reference to the following description for more details.In non-interactive mode, the application starts with the configuration specified on the
> command-line and immediately enters forwarding mode.
>
> * --portmask=0xXX
> Set the hexadecimal bitmask of the ports which can be used by the generic flow director test in packet forwarding.
>
> * --coremask=0xXX
> Set the hexadecimal bitmask of the cores running the packet forwarding test. The master
> lcore is reserved for command line parsing only and cannot be masked on for packet forwarding.
>
> * --nb-ports=N
> Set the number of forwarding ports, where 1 <= N <= "number of ports" on the board
> or CONFIG_RTE_MAX_ETHPORTS from the configuration file. The default value is the number of ports on the board.
>
> * --rxq=N
> Set the number of RX queues per port to N, where 1 <= N <= 65535. The default value is 1.
>
> * --txq=N
> Set the number of TX queues per port to N, where 1 <= N <= 65535. The default value is 1.
>
>
> ###this part need to complete later after decision of which EAL commands arguments need to be support in this application###
>
>
> Interactive mode
> ----------------
> * when the gen_filter application is started in interactive mode, (-i|--interactive), it displays a prompt
> that can be used to start and stop forwarding, and configure the application to set the Flow Director,
> display statistics, set the Flow Director and other tasks. The application has a number of commands line options:
>
> gen_filter>[Commands]
>
> * There is a prompt "gen_filter> " before cursor, command can be enter after that position,
> also a space bar between configuration file name and command.
>
> These are the commands that are currently working under the command line interface:
>
> * Control Commands
>
> help: show the following commands which are currently available in this application and their usage
> gen_filter>help
>
> quit: quits the application.
> gen_filter>quit
>
> start: start the application, start packet forwarding
> gen_filter>start
>
> stop: stop the application, stop packet forwarding
> gen_filter>stop
>
> showcfg: print configuration infomation about EAL parameters, for example mapping of cores, rx queue, tx queues and so on.
> gen_filter>showcfg
>
> * General Commands to add/remove/query an filter rule:
> App will print reminder message for user about whether this rule command is SUCESS or FAIL after user type in the commmand.
>
> add: add filter rules from configuration file
> gen_filter>add port_id filename.txt
> (port_id is the port index that user want to add filter rules, it can be any uint8_t integer.
> filename.txt is the rule configuration file name from which app read and paser port rules)
>
> del: remove filter rules from configuration file
> gen_filter>del port_id
> (port_id is the port index that user want to remove filter rules, it can be any uint8_t integer.)
>
> query: query filter statistics of rules from configuration file and dump results output to log file or printf
> gen_filter>query port_id query_reset action_name
> (port_id is the port index that user want to query statistics, it can be any uint8_t integer. query_reset is used for reset counters after query action,
> it must be integer 1 if youwant to reset counters after query, else 0. action_name is abbreviation of rte_flow_action_type which user want to query)
>
> display: display rules applying to that port
> gen_filter>display port_id
> (port_id is the port index that user want to add filter rules, it can be any uint8_t integer.)
>
>
>
> The rule configuration file
> ---------------------------
>
> 1.There is a mapping between rte_flow_item_type and configuration item type abbreviation for the convenience of writing:
>
> RTE_FLOW_ITEM_TYPE_END end
> RTE_FLOW_ITEM_TYPE_VOID void
> RTE_FLOW_ITEM_TYPE_INVERT invert
> RTE_FLOW_ITEM_TYPE_ANY any
> RTE_FLOW_ITEM_TYPE_PF pf
> RTE_FLOW_ITEM_TYPE_VF vf
> RTE_FLOW_ITEM_TYPE_PORT port
> RTE_FLOW_ITEM_TYPE_RAW raw
> RTE_FLOW_ITEM_TYPE_ETH eth
> RTE_FLOW_ITEM_TYPE_IPV4 ipv4
> RTE_FLOW_ITEM_TYPE_IPV6 ipv6
> RTE_FLOW_ITEM_TYPE_ICMP icmp
> RTE_FLOW_ITEM_TYPE_UDP udp
> RTE_FLOW_ITEM_TYPE_TCP tcp
> RTE_FLOW_ITEM_TYPE_SCTP sctp
> RTE_FLOW_ITEM_TYPE_VXLAN vxlan
>
> 2.There is a mapping between rte_flow_action_type and configuration action type abbreviation for the convenience of writing:
>
> RTE_FLOW_ACTION_TYPE_END ac_end
> RTE_FLOW_ACTION_TYPE_VOID ac_void
> RTE_FLOW_ACTION_TYPE_PASSTHRU ac_passthru
> RTE_FLOW_ACTION_TYPE_MARK ac_mark
> RTE_FLOW_ACTION_TYPE_FLAG ac_flag
> RTE_FLOW_ACTION_TYPE_QUEUE ac_queue
> RTE_FLOW_ACTION_TYPE_DROP ac_drop
> RTE_FLOW_ACTION_TYPE_COUNT ac_count
> RTE_FLOW_ACTION_TYPE_DUP ac_dup
> RTE_FLOW_ACTION_TYPE_RSS ac_rss
> RTE_FLOW_ACTION_TYPE_PF ac_pf
> RTE_FLOW_ACTION_TYPE_VF ac_vf
>
> 3.There is a mapping between struct rte_flow_attr and abbreviation for that configuration of writing:
>
> rte_flow_attr attr
>
> 4.Writing format of configuration file
>
> * write in one line for each rule
>
> * writing a "#" at the beginnning of line shows that it is a comment line, for example:
> ##########this is a comment line#########
>
> * flow pattern item name and action name should be as abbreviation as above
>
> * configuration file member has the same name as associated specification structure member, such as dst_addr/src_addr/type_of_service/time_to_live
> struct members of ipv4_hdr in specification rte_flow_item_ipv4
>
> * there should be a dash('/') between the structure member and its mask if it has a mask demand,
> mask format is XX...XX (where X - is a hexadecimal or decimal digit, case insensitive), and the number of X is according to the length of structure member,
> for example: rte_flow_item_ipv4 member time_to_live type is uint8_t, so its mask is also uint8_t such as time_to_live=20/0xf0, "f0" is its mask.
> And the user had better to provide every byte of the mask, for example, for a uint16 mask, abbreviative 0xf0 is also ok for mask 0x00f0,
> but the user must write IPv4/IPV6/Ethernet address mask explicitly and not use abbreviative style.
>
> * All these config element members such as time_to_live in rte_flow_item_ipv4, vtc_flow in rte_flow_item_ipv6 should be write in decimal or hexadecimal format,
> except for IPv6 and eth address list below.And pay attention to that all mask is using decimal or hexadecimal format. For example type_of_service=20/0xf0(or 0x14/0xf0) are both ok.
>
> * there should be an space bar(' ') between item name or action name and its structure member
>
> * there should be an equality sign('=') between structure member and assignment value, an space bar(' ') between two structure members
>
> * there should be an comma(',') between item names or action names
>
> * each IPv4 address input number should be decimal or hexadecimal in configuration file,
> > IPv4 address expected format:
> > src_addr (or dst_addr)=<src_ipv4_addr>'/'<mask> <space>
> > src_ipv4_addr format is xxx.xxx.xxx.xxx (where x - is a decimal or hexadecimal digit)
> > mask format is XX.XX.XX.XX (where X - is a decimal or hexadecimal digit, case insensitive)
> > <mask> can be negligible, the default mask is 0xff.0xff.0xff.0xff or 255.255.255.255
> such as IPv4 address 192.168.0.3(0xC0.0xA8.0.0x3), if there is a mask ffffff00 for that IPv4 address,there should be a dash before the mask,
> for example: src_addr=192.168.0.3/0xff.0xff.0xff.0x00 or src_addr=0xC0.0xA8.0x0.0x3/0xff.0xff.0xff.0x00
>
> * each IPv6 address input number should be hexadecimal in configuration file,
> > IPv6 address expected format:
> > src_addr (or dst_addr)=<src_ipv6_addr>'/'<mask> <space>
> > src_ipv6_addr and mask format is XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX (where X - is hexadecimal digit, case insensitive).
> > mask format is XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX (where X - is a decimal or hexadecimal digit, case insensitive), it don't support the brief style of IPv6 address.
> > <mask> can be negligible, the default mask is 0xffff:0xffff:0xffff:0xffff:0xffff:0xffff:0xffff:0xffff
> such as IPv6 address 2001:0000:3238:DFE1:0063:0000:0000:FEFB,if there is a prefix length or mask for that IPv6 address, there should be a dash before the prefix length,
> for example: src_addr=2001:0000:3238:DFE1:0063:0000:0000:FEFB/0x0000:0xFFFF:0xFFFF:0x0000:0x0000:0x0000:0x0000
>
> * each ethernet address input number should be hexadecimal in configuration file,
> > Ethernet address expected format:
> > src (or dst)=<src_eth_addr>'/'<mask> <space>
> > src_eth_addr_addr and mask format is XX-XX-XX-XX-XX-XX (where X - is a hexadecimal digit, case insensitive).
> > mask format is XX:XX:XX:XX:XX:XX (where X - is a decimal or hexadecimal digit, case insensitive)
> > <mask> can be negligible, the default mask is 0xff:0xff:0xff:0xff:0xff:0xff
> such as ethernet address a0:14:ff:36:95:b1, if there is a mask for that eth address, there should be a dash before the mask,
> for example: src=a0:14:ff:36:95:b1/0xff:0xff:0x00:0x00:0x00:0xff
>
> * item pattern or action structure containing array member need to assign each member of the array with the array name before value,
> for example: rte_flow_item_raw has array member pattern[], if it has 3 elements which are 10 11 20,so the configuration expected format is pattern={10&11&20}
>
> * item pattern or action structure containing structure array member or structure need to assign each member of the structure with the structure member
> name before value, for example: rte_flow_item_eth has structure array member tag[], if it has 2 elements which are tag[0]={10, 11} tag[1]={20, 21},
> so the configuration expected format is tag={{10&11}{20&21}}
>
> * Flow rule attributes should be configured if necessary for this rule, writing key word "attr" at first, configuration file member has the same name
> as struct rte_flow_attr member, for example: attr group=1 priority=0 ingress=1 egress=0
>
>
> Take the following 6 rules configuration as example:
> (a)Assign an IPv4 flow with specific source and destination IP address to Queue 8: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_IPV4, source address 192.168.100.15, subnet mask is 0xff.0xff.0xff.0x0,
> destination address 192.168.3.20, type_of_service is 20 with mask 0xf0, time_to_live 32, rte_flow_item_type is RTE_FLOW_ACTION_TYPE_QUEUE and queue index is 8, and Flow rule attributes is group in 1,
> priority is 0, ingress is 1 and egress is 0(apply noly to inbound traffic but not outbound traffic). There are attribute description and 2 items in flow pattern and 1 flow action.
>
> attr group=1 priority=0 ingress=1 egress=0, void, ipv4 src_addr=192.168.0.3/0xff.0xff.0xff.0x0 dst_addr=192.168.0.4 type_of_service=20/0xf0 time_to_live=32, ac_queue queue=8
>
> (b)Assign an IPv6 flow with the certain packet length from and to specific IP address to the certain vf: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_IPV6,
> source address is 2001:0000:3238:DFE1:0063:0000:0000:FEFB, the mask is 0x0000:0xFFFF:0xFFFF:0x0000:0x0000:0x0000:0x0000, destination address is 2001:0000:3238:DFE1:0063:0000:0000:0A23,
> payload_len 1024,rte_flow_action_type is RTE_FLOW_ACTION_TYPE_VF and RTE_FLOW_ACTION_TYPE_COUNT, redirect the packet to a vf and enables counters for this rule, there is 1 item in flow pattern and 2 flow action.
>
> ipv6 src_addr=2001:0000:3238:DFE1:0063:0000:0000:FEFB/0x0000:0xFFFF:0xFFFF:0x0000:0x0000:0x0000:0x0000 dst_addr=2001:0000:3238:DFE1:0063:0000:0000:0A23 payload_len=1024 vtc_flow=255/0xff, ac_vf original=1 vf=2, ac_count
>
> (c)A flow with RSS usage for specific MAC address Ethernet packets redirected to Queue 0 and 3: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_ETH, source address is a0:14:ff:36:95:b1 and its mask is 0xff:0xff:0x00:0x00:0x00:0xff,
> destination address is b0:24:ff:36:95:f2 and its mask is default 0xff:0xff:0xff:0xff:0xff:0xff, 2 tag elements is tag[0]={10, 11} tag[1]={20, 21},
> rte_flow_action_type is RTE_FLOW_ACTION_TYPE_RSS, queue index is 0 and 3
>
> eth src=a0:14:ff:36:95:b1/0xff:0xff:0x00:0x00:0x00:0xff dst=b0:24:ff:36:95:f2 tag={{10&11}{20&21}}, ac_rss queue={0&3}
>
> (d)Add a 32 bit value to a VLAN packet to return with that mark: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_VXLAN, VXLAN network identifier index is 11, flags is 0x8 and the 32 bit value is 0x1a2b3c4d
> rte_flow_action_type is RTE_FLOW_ACTION_TYPE_MARK
>
> vxlan flags=0x8 vni=11, ac_mark mark=0x1a2b3c4d
>
> (e)Drop cerstain specific TCP packets: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_TCP, src_port is 80, sent_seq is 726, tcp_flags is 2
> rte_flow_action_type is RTE_FLOW_ACTION_TYPE_DROP
>
> tcp src_port=80 sent_seq=726 tcp_flags=2, ac_drop
>
> (f)Redirect some UDP packets into a specific queue: rte_flow_item_type is RTE_FLOW_ITEM_TYPE_UDP, src_port is 21, dst_port is 21,
> rte_flow_action_type is RTE_FLOW_ACTION_TYPE_QUEUE, queue index is 1
>
> udp src_port=21 dst_port=21, ac_queue queue=1
>
>
> Explanation
> -----------
>
> The following sections provide an explanation of the main components of the app code:
> main function
> -------------
> * open configuration file and parser the simple rules, then call a few rule management functions in order to
> fully manage flows. Each created flow rule is associated with an opaque, PMD-specific handle pointer.
> The application is responsible for keeping it until the rule is destroyed.
>
> packet forward function
> -----------------------
> * Forwards packets "as-is" in I/O mode. This is the fastest possible forwarding operation
> as it does not access packets data. This is the default mode of this example.
>
> rule management function
> ------------------------
>
> * Check whether a flow rule can be created on a given port
>
> * Create a flow rule on a given port.
>
> * Query an existing flow rule on a given port.
>
> * Destroy a flow rule on a given port.
>
> * Destroy all flow rules associated with a port.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix wrong use of vector instruction
From: Adrien Mazarguil @ 2016-11-02 15:56 UTC (permalink / raw)
To: Elad Persiko; +Cc: dev
In-Reply-To: <1477988007-26141-1-git-send-email-eladpe@mellanox.com>
On Tue, Nov 01, 2016 at 08:13:27AM +0000, Elad Persiko wrote:
> Constraint alignment was not respected in Tx.
>
> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>
> Signed-off-by: Elad Persiko <eladpe@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index 21164ba..ba8e202 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -309,7 +309,7 @@ mlx5_tx_dbrec(struct txq *txq)
> *txq->qp_db = htonl(txq->wqe_ci);
> /* Ensure ordering between DB record and BF copy. */
> rte_wmb();
> - rte_mov16(dst, (uint8_t *)data);
> + memcpy(dst, (uint8_t *)data, 16);
> txq->bf_offset ^= (1 << txq->bf_buf_size);
> }
>
> @@ -449,7 +449,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
> wqe->eseg.mss = 0;
> wqe->eseg.rsvd2 = 0;
> /* Start by copying the Ethernet Header. */
> - rte_mov16((uint8_t *)raw, (uint8_t *)addr);
> + memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
> length -= MLX5_WQE_DWORD_SIZE;
> addr += MLX5_WQE_DWORD_SIZE;
> /* Replace the Ethernet type by the VLAN if necessary. */
> --
> 1.8.3.1
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH 0/3] fix Rx checksum offloads
From: Adrien Mazarguil @ 2016-11-02 15:57 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
In-Reply-To: <cover.1478082521.git.nelio.laranjeiro@6wind.com>
On Wed, Nov 02, 2016 at 11:39:36AM +0100, Nelio Laranjeiro wrote:
> Fill correctly the Mbuf Rx offloads.
>
> Nelio Laranjeiro (3):
> net/mlx5: fix Rx checksum macros
> net/mlx5: define explicit fields for Rx offloads
> net/mlx: fix support for new Rx checksum flags
>
> drivers/net/mlx4/mlx4.c | 21 ++++------
> drivers/net/mlx5/mlx5_prm.h | 37 +++++++++++++++++-
> drivers/net/mlx5/mlx5_rxtx.c | 93 ++++++++++++++++++++------------------------
> 3 files changed, 87 insertions(+), 64 deletions(-)
>
> --
> 2.1.4
Thanks. For the series:
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox