* Re: [PATCH v3 2/7] vhost: get guest/host physical address mappings
From: linhaifeng @ 2016-11-29 3:10 UTC (permalink / raw)
To: dev
In-Reply-To: <1475998080-4644-3-git-send-email-yuanhan.liu@linux.intel.com>
在 2016/10/9 15:27, Yuanhan Liu 写道:
> + dev->nr_guest_pages = 0;
> + if (!dev->guest_pages) {
> + dev->max_guest_pages = 8;
> + dev->guest_pages = malloc(dev->max_guest_pages *
> + sizeof(struct guest_page));
> + }
> +
when to free guest_pages ?
^ permalink raw reply
* Re: [PATCH 2/4] eventdev: implement the northbound APIs
From: Jerin Jacob @ 2016-11-29 3:43 UTC (permalink / raw)
To: Eads, Gage
Cc: dev@dpdk.org, Richardson, Bruce, Van Haaren, Harry,
hemant.agrawal@nxp.com
In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01E33E96@FMSMSX108.amr.corp.intel.com>
On Mon, Nov 28, 2016 at 03:53:08PM +0000, Eads, Gage wrote:
> (Bruce's adviced heeded :))
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Tuesday, November 22, 2016 5:44 PM
> > To: Eads, Gage <gage.eads@intel.com>
> > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Van
> > Haaren, Harry <harry.van.haaren@intel.com>; hemant.agrawal@nxp.com
> > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs
> >
> > On Tue, Nov 22, 2016 at 10:48:32PM +0000, Eads, Gage wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > > Sent: Tuesday, November 22, 2016 2:00 PM
> > > > To: Eads, Gage <gage.eads@intel.com>
> > > > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>;
> > > > Van Haaren, Harry <harry.van.haaren@intel.com>;
> > > > hemant.agrawal@nxp.com
> > > > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the
> > > > northbound APIs
> > > >
> > > > On Tue, Nov 22, 2016 at 07:43:03PM +0000, Eads, Gage wrote:
> > > > > > > > > > One open issue I noticed is the "typical workflow"
> > > > > > description starting in > > rte_eventdev.h:204 conflicts with
> > > > the > > centralized software PMD that Harry > > posted last week.
> > > > > > Specifically, that PMD expects a single core to call the > >
> > > > > > schedule function. We could extend the documentation to account
> > > > for > > this > > alternative style of scheduler invocation, or
> > > > discuss > > ways to make the software > > PMD work with the
> > > > documented > > workflow. I prefer the former, but either way I >
> > > > > think we > > ought to expose the scheduler's expected usage to
> > > > the user -- > > perhaps > > through an RTE_EVENT_DEV_CAP flag?
> > > > > > > > >
> > > > > > > > > I prefer former too, you can propose the documentation
> > > > > > change required for > > software PMD.
> > > > > > >
> > > > > > > Sure, proposal follows. The "typical workflow" isn't the
> > > > most > > optimal by having a conditional in the fast-path, of
> > > > course, but it > > demonstrates the idea simply.
> > > > > > >
> > > > > > > (line 204)
> > > > > > > * An event driven based application has following typical
> > > > > > workflow on > > fastpath:
> > > > > > > * \code{.c}
> > > > > > > * while (1) {
> > > > > > > *
> > > > > > > * if (dev_info.event_dev_cap &
> > > > > > > * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED)
> > > > > > > * rte_event_schedule(dev_id);
> > > > > >
> > > > > > Yes, I like the idea of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED.
> > > > > > It can be input to application/subsystem to launch separate
> > > > > > core(s) for schedule functions.
> > > > > > But, I think, the "dev_info.event_dev_cap & > >
> > > > RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED"
> > > > > > check can be moved inside the implementation(to make the
> > > > better > > decisions and avoiding consuming cycles on HW based
> > schedulers.
> > > > >
> > > > > How would this check work? Wouldn't it prevent any core from
> > > > running the software scheduler in the centralized case?
> > > >
> > > > I guess you may not need RTE_EVENT_DEV_CAP here, instead need flag
> > > > for device configure here
> > > >
> > > > #define RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED (1ULL << 1)
> > > >
> > > > struct rte_event_dev_config config; config.event_dev_cfg =
> > > > RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED;
> > > > rte_event_dev_configure(.., &config);
> > > >
> > > > on the driver side on configure,
> > > > if (config.event_dev_cfg & RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED)
> > > > eventdev->schedule = NULL;
> > > > else // centralized case
> > > > eventdev->schedule = your_centrized_schedule_function;
> > > >
> > > > Does that work?
> > >
> > > Hm, I fear the API would give users the impression that they can select the
> > scheduling behavior of a given eventdev, when a software scheduler is more
> > likely to be either distributed or centralized -- not both.
> >
> > Even if it is capability flag then also it is per "device". Right ?
> > capability flag is more of read only too. Am i missing something here?
> >
>
> Correct, the capability flag I'm envisioning is per-device and read-only.
>
> > >
> > > What if we use the capability flag, and define rte_event_schedule() as the
> > scheduling function for centralized schedulers and rte_event_dequeue() as the
> > scheduling function for distributed schedulers? That way, the datapath could be
> > the simple dequeue -> process -> enqueue. Applications would check the
> > capability flag at configuration time to decide whether or not to launch an
> > lcore that calls rte_event_schedule().
> >
> > I am all for simple "dequeue -> process -> enqueue".
> > rte_event_schedule() added for SW scheduler only, now it may not make sense
> > to add one more check on top of "rte_event_schedule()" to see it is really need
> > or not in fastpath?
> >
>
> Yes, the additional check shouldn't be needed. In terms of the 'typical workflow' description, this is what I have in mind:
>
> *
> * An event driven based application has following typical workflow on fastpath:
> * \code{.c}
> * while (1) {
> *
> * rte_event_dequeue(...);
> *
> * (event processing)
> *
> * rte_event_enqueue(...);
> * }
> * \endcode
> *
> * The events are injected to event device through the *enqueue* operation by
> * event producers in the system. The typical event producers are ethdev
> * subsystem for generating packet events, core(SW) for generating events based
> * on different stages of application processing, cryptodev for generating
> * crypto work completion notification etc
> *
> * The *dequeue* operation gets one or more events from the event ports.
> * The application process the events and send to downstream event queue through
> * rte_event_enqueue() if it is an intermediate stage of event processing, on
> * the final stage, the application may send to different subsystem like ethdev
> * to send the packet/event on the wire using ethdev rte_eth_tx_burst() API.
> *
> * The point at which events are scheduled to ports depends on the device. For
> * hardware devices, scheduling occurs asynchronously. Software schedulers can
> * either be distributed (each worker thread schedules events to its own port)
> * or centralized (a dedicated thread schedules to all ports). Distributed
> * software schedulers perform the scheduling in rte_event_dequeue(), whereas
> * centralized scheduler logic is located in rte_event_schedule(). The
> * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag indicates whether a
> * device is centralized and thus needs a dedicated scheduling thread that
Since we are starting a dedicated thread in centralized
case, How about name the flag as RTE_EVENT_DEV_CAP_CENTRALIZED_SCHED?
instead of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED.
No strong opinion here. Just a thought.
> * repeatedly calls rte_event_schedule().
> *
> */
^ permalink raw reply
* Re: [PATCH 1/4] eventdev: introduce event driven programming model
From: Jerin Jacob @ 2016-11-29 4:01 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, dev, harry.van.haaren, hemant.agrawal, gage.eads
In-Reply-To: <20161128091610.GB168972@bricha3-MOBL3.ger.corp.intel.com>
On Mon, Nov 28, 2016 at 09:16:10AM +0000, Bruce Richardson wrote:
> On Sat, Nov 26, 2016 at 08:24:55AM +0530, Jerin Jacob wrote:
> > On Fri, Nov 25, 2016 at 11:00:53AM +0000, Bruce Richardson wrote:
> > > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote:
> > > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote:
> > > > > 2016-11-24 07:29, Jerin Jacob:
> > > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
> > > > > > > 2016-11-18 11:14, Jerin Jacob:
> > > > > > > > +Eventdev API - EXPERIMENTAL
> > > > > > > > +M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > > > > > +F: lib/librte_eventdev/
> > > > > > >
> > > >
> > > > I don't think there is any portability issue here, I can explain.
> > > >
> > > > The application level, we have two more use case to deal with non burst
> > > > variant
> > > >
> > > > - latency critical work
> > > > - on dequeue, if application wants to deal with only one flow(i.e to
> > > > avoid processing two different application flows to avoid cache trashing)
> > > >
> > > > Selection of the burst variants will be based on
> > > > rte_event_dev_info_get() and rte_event_dev_configure()(see, max_event_port_dequeue_depth,
> > > > max_event_port_enqueue_depth, nb_event_port_dequeue_depth, nb_event_port_enqueue_depth )
> > > > So I don't think their is portability issue here and I don't want to waste my
> > > > CPU cycles on the for loop if application known to be working with non
> > > > bursts variant like below
> > > >
> > >
> > > If the application is known to be working on non-burst varients, then
> > > they always request a burst-size of 1, and skip the loop completely.
> > > There is no extra performance hit in that case in either the app or the
> > > driver (since the non-burst driver always returns 1, irrespective of the
> > > number requested).
> >
> > Hmm. I am afraid, There is.
> > On the app side, the const "1" can not be optimized by the compiler as
> > on downside it is function pointer based driver interface
> > On the driver side, the implementation would be for loop based instead
> > of plain access.
> > (compiler never can see the const "1" in driver interface)
> >
> > We are planning to implement burst mode as kind of emulation mode and
> > have a different scheme for burst and nonburst. The similar approach we have
> > taken in introducing rte_event_schedule() and split the responsibility so
> > that SW driver can work without additional performance overhead and neat
> > driver interface.
> >
> > If you are concerned about the usability part and regression on the SW
> > driver, then it's not the case, application will use nonburst variant only if
> > dequeue_depth == 1 and/or explicit case where latency matters.
> >
> > On the portability side, we support both case and application if written based
> > on dequeue_depth it will perform well in both implementations.IMO, There is
> > no another shortcut for performance optimized application running on different
> > set of model.I think it is not an issue as, in event model as each cores
> > identical and main loop can be changed based on dequeue_depth
> > if needs performance(anyway mainloop will be function pointer based).
> >
>
> Ok, I think I see your point now. Here is an alternative suggestion.
>
> 1. Keep the single user API.
> 2. Have both single and burst function pointers in the driver
> 3. Call appropriately in the eventdev layer based on parameters. For
> example:
>
> rte_event_dequeue_burst(..., int num)
> {
> if (num == 1 && single_dequeue_fn != NULL)
> return single_dequeue_fn(...);
> return burst_dequeue_fn(...);
> }
>
> This way drivers can optionally special-case the single dequeue case -
> the function pointer check will definitely be predictable in HW making
> that a near-zero-cost check - while not forcing all drivers to do so.
> It also reduces the public API surface, and gives us a single enqueue
> and dequeue function.
The alternative suggestion looks good to me. Yes, it makes sense to reduces the
public API interface if possible.
Regarding the implementation, I thought to have a bit approach like below
to reduce the cost of additional AND operation.(with const "1", compiler
can choose with correct one with out any overhead)
rte_event_dequeue_burst(..., int num)
{
if (num == 1)
return single_dequeue_fn(...);
return burst_dequeue_fn(...);
}
"single_dequeue_fn" populated from the driver layer.
In the absence of populating the "single_dequeue_fn" from the driver layer,
The common code can create the single_dequeue_fn using driver
provided "burst_dequeue_fn"
something like
generic_single_dequeue_fn(dev){
{
dev->burst_dequeue_fn(..,1);
}
Any concerns?
>
> /Bruce
>
^ permalink raw reply
* Re: [PATCH 2/4] eventdev: implement the northbound APIs
From: Eads, Gage @ 2016-11-29 5:46 UTC (permalink / raw)
To: Jerin Jacob
Cc: dev@dpdk.org, Richardson, Bruce, Van Haaren, Harry,
hemant.agrawal@nxp.com
In-Reply-To: <20161129034304.GB9930@svelivela-lt.caveonetworks.com>
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Monday, November 28, 2016 9:43 PM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Van
> Haaren, Harry <harry.van.haaren@intel.com>; hemant.agrawal@nxp.com
> Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the northbound APIs
>
> On Mon, Nov 28, 2016 at 03:53:08PM +0000, Eads, Gage wrote:
> > (Bruce's adviced heeded :))
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > Sent: Tuesday, November 22, 2016 5:44 PM
> > > To: Eads, Gage <gage.eads@intel.com>
> > > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>;
> > > Van Haaren, Harry <harry.van.haaren@intel.com>;
> > > hemant.agrawal@nxp.com
> > > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the
> > > northbound APIs
> > >
> > > On Tue, Nov 22, 2016 at 10:48:32PM +0000, Eads, Gage wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > > > Sent: Tuesday, November 22, 2016 2:00 PM > > To: Eads, Gage
> > > <gage.eads@intel.com> > > Cc: dev@dpdk.org; Richardson, Bruce
> > > <bruce.richardson@intel.com>; > > Van Haaren, Harry
> > > <harry.van.haaren@intel.com>; > > hemant.agrawal@nxp.com > >
> > > Subject: Re: [dpdk-dev] [PATCH 2/4] eventdev: implement the > >
> > > northbound APIs > > > > On Tue, Nov 22, 2016 at 07:43:03PM +0000,
> > > Eads, Gage wrote:
> > > > > > > > > > > One open issue I noticed is the "typical workflow"
> > > > > > > description starting in > > rte_eventdev.h:204 conflicts
> > > with > > the > > centralized software PMD that Harry > > posted last
> week.
> > > > > > > Specifically, that PMD expects a single core to call the
> > > > > > > > > schedule function. We could extend the documentation to
> > > account > > for > > this > > alternative style of scheduler
> > > invocation, or > > discuss > > ways to make the software > >
> > > PMD work with the > > documented > > workflow. I prefer the
> > > former, but either way I > > > > think we > > ought to expose
> > > the scheduler's expected usage to > > the user -- > > perhaps > > through
> an RTE_EVENT_DEV_CAP flag?
> > > > > > > > > >
> > > > > > > > > > I prefer former too, you can propose the
> > > documentation > > > > change required for > > software PMD.
> > > > > > > >
> > > > > > > > Sure, proposal follows. The "typical workflow" isn't
> > > the > > most > > optimal by having a conditional in the
> > > fast-path, of > > course, but it > > demonstrates the idea simply.
> > > > > > > >
> > > > > > > > (line 204)
> > > > > > > > * An event driven based application has following
> > > typical > > > > workflow on > > fastpath:
> > > > > > > > * \code{.c}
> > > > > > > > * while (1) {
> > > > > > > > *
> > > > > > > > * if (dev_info.event_dev_cap &
> > > > > > > > * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED)
> > > > > > > > * rte_event_schedule(dev_id);
> > > > > > >
> > > > > > > Yes, I like the idea of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED.
> > > > > > > It can be input to application/subsystem to launch
> > > separate > > > > core(s) for schedule functions.
> > > > > > > But, I think, the "dev_info.event_dev_cap & > > > >
> > > RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED"
> > > > > > > check can be moved inside the implementation(to make the
> > > > > better > > decisions and avoiding consuming cycles on HW
> > > based schedulers.
> > > > > >
> > > > > > How would this check work? Wouldn't it prevent any core from
> > > > > running the software scheduler in the centralized case?
> > > > >
> > > > > I guess you may not need RTE_EVENT_DEV_CAP here, instead need
> > > flag > > for device configure here > > > > #define
> > > RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED (1ULL << 1) > > > > struct
> > > rte_event_dev_config config; config.event_dev_cfg = > >
> > > RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED;
> > > > > rte_event_dev_configure(.., &config); > > > > on the driver
> > > side on configure, > > if (config.event_dev_cfg &
> > > RTE_EVENT_DEV_CFG_DISTRIBUTED_SCHED)
> > > > > eventdev->schedule = NULL;
> > > > > else // centralized case
> > > > > eventdev->schedule = your_centrized_schedule_function;
> > > > >
> > > > > Does that work?
> > > >
> > > > Hm, I fear the API would give users the impression that they can
> > > select the scheduling behavior of a given eventdev, when a software
> > > scheduler is more likely to be either distributed or centralized -- not both.
> > >
> > > Even if it is capability flag then also it is per "device". Right ?
> > > capability flag is more of read only too. Am i missing something here?
> > >
> >
> > Correct, the capability flag I'm envisioning is per-device and read-only.
> >
> > > >
> > > > What if we use the capability flag, and define
> > > rte_event_schedule() as the scheduling function for centralized
> > > schedulers and rte_event_dequeue() as the scheduling function for
> > > distributed schedulers? That way, the datapath could be the simple
> > > dequeue -> process -> enqueue. Applications would check the
> > > capability flag at configuration time to decide whether or not to launch an
> lcore that calls rte_event_schedule().
> > >
> > > I am all for simple "dequeue -> process -> enqueue".
> > > rte_event_schedule() added for SW scheduler only, now it may not
> > > make sense to add one more check on top of "rte_event_schedule()"
> > > to see it is really need or not in fastpath?
> > >
> >
> > Yes, the additional check shouldn't be needed. In terms of the 'typical
> workflow' description, this is what I have in mind:
> >
> > *
> > * An event driven based application has following typical workflow on
> fastpath:
> > * \code{.c}
> > * while (1) {
> > *
> > * rte_event_dequeue(...);
> > *
> > * (event processing)
> > *
> > * rte_event_enqueue(...);
> > * }
> > * \endcode
> > *
> > * The events are injected to event device through the *enqueue*
> > operation by
> > * event producers in the system. The typical event producers are
> > ethdev
> > * subsystem for generating packet events, core(SW) for generating
> > events based
> > * on different stages of application processing, cryptodev for
> > generating
> > * crypto work completion notification etc
> > *
> > * The *dequeue* operation gets one or more events from the event ports.
> > * The application process the events and send to downstream event
> > queue through
> > * rte_event_enqueue() if it is an intermediate stage of event
> > processing, on
> > * the final stage, the application may send to different subsystem
> > like ethdev
> > * to send the packet/event on the wire using ethdev rte_eth_tx_burst() API.
> > *
> > * The point at which events are scheduled to ports depends on the
> > device. For
> > * hardware devices, scheduling occurs asynchronously. Software
> > schedulers can
> > * either be distributed (each worker thread schedules events to its
> > own port)
> > * or centralized (a dedicated thread schedules to all ports).
> > Distributed
> > * software schedulers perform the scheduling in rte_event_dequeue(),
> > whereas
> > * centralized scheduler logic is located in rte_event_schedule(). The
> > * RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag indicates
> > whether a
> > * device is centralized and thus needs a dedicated scheduling thread
> > that
>
> Since we are starting a dedicated thread in centralized case, How about name
> the flag as RTE_EVENT_DEV_CAP_CENTRALIZED_SCHED?
> instead of RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED.
> No strong opinion here. Just a thought.
>
Fine with me.
^ permalink raw reply
* [PATCH v3] maintainers: update testpmd maintainer
From: Jingjing Wu @ 2016-11-29 7:58 UTC (permalink / raw)
To: dev; +Cc: jingjing.wu, pablo.de.lara.guarch
In-Reply-To: <1480312850-14656-1-git-send-email-jingjing.wu@intel.com>
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
v1 change:
remove pablo from maintainer.
v2 change:
remove Wei Dai from claim.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d6bb8f8..fd096c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -614,7 +614,7 @@ F: app/test/virtual_pmd.c
F: app/test/virtual_pmd.h
Driver testing tool
-M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
+M: Jingjing Wu <jingjing.wu@intel.com>
F: app/test-pmd/
F: doc/guides/testpmd_app_ug/
--
2.4.11
^ permalink raw reply related
* Re: dpdk/vpp and cross-version migration for vhost
From: Maxime Coquelin @ 2016-11-29 8:09 UTC (permalink / raw)
To: Thomas Monjalon, Kavanagh, Mark B, Kevin Traynor, Yuanhan Liu
Cc: dev, Weglicki, MichalX, Michael S. Tsirkin, Stephen Hemminger,
qemu-devel, libvir-list, vpp-dev, Marc-André Lureau,
olivier.matz
In-Reply-To: <5176838.Upmb1ZYUhB@xps13>
On 11/28/2016 11:18 PM, Thomas Monjalon wrote:
> 2016-11-28 16:28, Maxime Coquelin:
>> On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote:
>>> DPDK v16.04 added support for vHost User TSO; as such, by default,
>>> TSO is advertised to guest devices as an available feature during
>>> feature negotiation with QEMU.
>>> However, while the vHost user backend sets up the majority of the
>>> mbuf fields that are required for TSO, there is still a reliance
>>> on the associated DPDK application (i.e. in this case OvS-DPDK)
>>> to set the remaining flags and/or offsets.
>>> Since OvS-DPDK doesn't currently provide that functionality, it is
>>> necessary to explicitly disable TSO; otherwise, undefined behaviour
>>> will ensue.
>>
>> Thanks Mark for the clarification.
>>
>> In this case, maybe we could add a DPDK build option to disable Vhost's
>> TSO support, that would be selected for OVS packages?
>
> Why do you prefer a build-time option rather than the run-time config
> with rte_vhost_feature_disable()? Because we need to lock the features?
Right, we need to know what the backend supports before it is started,
so that management tool can check where it could be migrated to.
>
> Reminder: build-time configuration options are forbidden in DPDK for
> such usage. It would prevent other applications from using the feature
> in a given distribution, just because it is not implemented in OVS.
I understand, this is not the right solution.
I proposed this because I misunderstood how the distributions package
OVS+DPDK.
>
>> Does that sound reasonable?
>
> Maybe I'm missing something but I feel it is more reasonnable to implement
> the missing code in OVS.
Yes, that would be the ideal solution.
OVS implements TSO and we let management tool decide whether or not
enabling the features.
While this is done, we could deprecate rte_vhost_feature_disable, and
print error message notifying the user it should be done my the
management tool.
> If something is missing in DPDK, do not hesitate to request or add more
> helper functions.
Sure.
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH] eal: define generic vector types
From: Chao Zhu @ 2016-11-29 8:12 UTC (permalink / raw)
To: 'Nelio Laranjeiro', dev
Cc: 'Thomas Monjalon', 'Jianbo Liu',
'Jerin Jacob', 'Zhigang Lu', 'Liming Sun',
'Bruce Richardson', 'Konstantin Ananyev',
'Adrien Mazarguil'
In-Reply-To: <3ce1da9662dcf59950f43643c14cc14e972f0429.1479309557.git.nelio.laranjeiro@6wind.com>
-----Original Message-----
From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
Sent: 2016年11月16日 23:21
To: dev@dpdk.org
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Jianbo Liu
<jianbo.liu@linaro.org>; Jerin Jacob <jerin.jacob@caviumnetworks.com>;
Zhigang Lu <zlu@ezchip.com>; Liming Sun <lsun@ezchip.com>; Chao Zhu
<chaozhu@linux.vnet.ibm.com>; Bruce Richardson <bruce.richardson@intel.com>;
Konstantin Ananyev <konstantin.ananyev@intel.com>; Adrien Mazarguil <adrien.
mazarguil@6wind.com>
Subject: [PATCH] eal: define generic vector types
Add common vector type definitions to all CPU architectures.
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
lib/librte_eal/common/Makefile | 1 +
lib/librte_eal/common/include/arch/arm/rte_vect.h | 1 +
.../common/include/arch/ppc_64/rte_vect.h | 1 +
lib/librte_eal/common/include/arch/tile/rte_vect.h | 38 +++++
lib/librte_eal/common/include/arch/x86/rte_vect.h | 7 +-
lib/librte_eal/common/include/generic/rte_vect.h | 185
+++++++++++++++++++++
6 files changed, 230 insertions(+), 3 deletions(-) create mode 100644
lib/librte_eal/common/include/arch/tile/rte_vect.h
create mode 100644 lib/librte_eal/common/include/generic/rte_vect.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index dfd64aa..8af06b1 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -48,6 +48,7 @@ endif
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h
+GENERIC_INC += rte_vect.h
# defined in mk/arch/$(RTE_ARCH)/rte.vars.mk ARCH_DIR ?= $(RTE_ARCH)
ARCH_INC := $(notdir $(wildcard
$(RTE_SDK)/lib/librte_eal/common/include/arch/$(ARCH_DIR)/*.h))
diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h
b/lib/librte_eal/common/include/arch/arm/rte_vect.h
index b86c2cf..4107c99 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
@@ -34,6 +34,7 @@
#define _RTE_VECT_ARM_H_
#include <stdint.h>
+#include "generic/rte_vect.h"
#include "arm_neon.h"
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
index 05209e5..99586e5 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h
@@ -34,6 +34,7 @@
#define _RTE_VECT_PPC_64_H_
#include <altivec.h>
+#include "generic/rte_vect.h"
#ifdef __cplusplus
extern "C" {
diff --git a/lib/librte_eal/common/include/arch/tile/rte_vect.h
b/lib/librte_eal/common/include/arch/tile/rte_vect.h
new file mode 100644
index 0000000..f1e1709
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/tile/rte_vect.h
@@ -0,0 +1,38 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright 2016 6WIND S.A.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of 6WIND S.A. nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_VECT_TILE_H_
+#define _RTE_VECT_TILE_H_
+
+#include "generic/rte_vect.h"
+
+#endif /* _RTE_VECT_TILE_H_ */
diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h
b/lib/librte_eal/common/include/arch/x86/rte_vect.h
index 77f2e25..1b4b85d 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
@@ -31,8 +31,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#ifndef _RTE_VECT_H_
-#define _RTE_VECT_H_
+#ifndef _RTE_VECT_X86_H_
+#define _RTE_VECT_X86_H_
/**
* @file
@@ -41,6 +41,7 @@
*/
#include <stdint.h>
+#include "generic/rte_vect.h"
#if (defined(__ICC) || (__GNUC__ == 4 && __GNUC_MINOR__ < 4))
@@ -133,4 +134,4 @@ __extension__ ({ \
}
#endif
-#endif /* _RTE_VECT_H_ */
+#endif /* _RTE_VECT_X86_H_ */
diff --git a/lib/librte_eal/common/include/generic/rte_vect.h
b/lib/librte_eal/common/include/generic/rte_vect.h
new file mode 100644
index 0000000..d7b9cd9
--- /dev/null
+++ b/lib/librte_eal/common/include/generic/rte_vect.h
@@ -0,0 +1,185 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright 2016 6WIND S.A.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of 6WIND S.A. nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_VECT_H_
+#define _RTE_VECT_H_
+
+#include <stdint.h>
+
+/* Unsigned vector types. */
+
+/*
+ * 64 bits vector size to use with unsigned 8 bits elements.
+ * a = (rte_v64u8_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+uint8_t rte_v64u8_t __attribute__((vector_size(8), aligned(8)));
+
+/*
+ * 64 bits vector size to use with unsigned 16 bits elements.
+ * a = (rte_v64u16_t){ a0, a1, a2, a3 } */ typedef uint16_t
+rte_v64u16_t __attribute__((vector_size(8), aligned(8)));
+
+/*
+ * 64 bits vector size to use with unsigned 32 bits elements.
+ * a = (rte_v64u32_t){ a0, a1 }
+ */
+typedef uint32_t rte_v64u32_t __attribute__((vector_size(8),
+aligned(8)));
+
+/*
+ * 128 bits vector size to use with unsigned 8 bits elements.
+ * a = (rte_v128u8_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15 }
+ */
+typedef uint8_t rte_v128u8_t __attribute__((vector_size(16),
+aligned(16)));
+
+/*
+ * 128 bits vector size to use with unsigned 16 bits elements.
+ * a = (rte_v128u16_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+uint16_t rte_v128u16_t __attribute__((vector_size(16), aligned(16)));
+
+/*
+ * 128 bits vector size to use with unsigned 32 bits elements.
+ * a = (rte_v128u32_t){ a0, a1, a2, a3, a4 } */ typedef uint32_t
+rte_v128u32_t __attribute__((vector_size(16), aligned(16)));
+
+/*
+ * 128 bits vector size to use with unsigned 64 bits elements.
+ * a = (rte_v128u64_t){ a0, a1 }
+ */
+typedef uint64_t rte_v128u64_t __attribute__((vector_size(16),
+aligned(16)));
+
+/*
+ * 256 bits vector size to use with unsigned 8 bits elements.
+ * a = (rte_v256u8_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15,
+ * a16, a17, a18, a19, a20, a21, a22, a23,
+ * a24, a25, a26, a27, a28, a29, a30, a31 }
+ */
+typedef uint8_t rte_v256u8_t __attribute__((vector_size(32),
+aligned(32)));
+
+/*
+ * 256 bits vector size to use with unsigned 16 bits elements.
+ * a = (rte_v256u16_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15 }
+ */
+typedef uint16_t rte_v256u16_t __attribute__((vector_size(32),
+aligned(32)));
+
+/*
+ * 256 bits vector size to use with unsigned 32 bits elements.
+ * a = (rte_v256u32_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+uint32_t rte_v256u32_t __attribute__((vector_size(32), aligned(32)));
+
+/*
+ * 256 bits vector size to use with unsigned 64 bits elements.
+ * a = (rte_v256u64_t){ a0, a1, a2, a3 } */ typedef uint64_t
+rte_v256u64_t __attribute__((vector_size(32), aligned(32)));
+
+
+/* Signed vector types. */
+
+/*
+ * 64 bits vector size to use with 8 bits elements.
+ * a = (rte_v64s8_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+int8_t rte_v64s8_t __attribute__((vector_size(8), aligned(8)));
+
+/*
+ * 64 bits vector size to use with 16 bits elements.
+ * a = (rte_v64s16_t){ a0, a1, a2, a3 } */ typedef int16_t
+rte_v64s16_t __attribute__((vector_size(8), aligned(8)));
+
+/*
+ * 64 bits vector size to use with 32 bits elements.
+ * a = (rte_v64s32_t){ a0, a1 }
+ */
+typedef int32_t rte_v64s32_t __attribute__((vector_size(8),
+aligned(8)));
+
+/*
+ * 128 bits vector size to use with 8 bits elements.
+ * a = (rte_v128s8_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15 }
+ */
+typedef int8_t rte_v128s8_t __attribute__((vector_size(16),
+aligned(16)));
+
+/*
+ * 128 bits vector size to use with 16 bits elements.
+ * a = (rte_v128s16_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+int16_t rte_v128s16_t __attribute__((vector_size(16), aligned(16)));
+
+/*
+ * 128 bits vector size to use with 32 bits elements.
+ * a = (rte_v128s32_t){ a0, a1, a2, a3 } */ typedef int32_t
+rte_v128s32_t __attribute__((vector_size(16), aligned(16)));
+
+/*
+ * 128 bits vector size to use with 64 bits elements.
+ * a = (rte_v128s64_t){ a1, a2 }
+ */
+typedef int64_t rte_v128s64_t __attribute__((vector_size(16),
+aligned(16)));
+
+/*
+ * 256 bits vector size to use with 8 bits elements.
+ * a = (rte_v256s8_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15,
+ * a16, a17, a18, a19, a20, a21, a22, a23,
+ * a24, a25, a26, a27, a28, a29, a30, a31 }
+ */
+typedef int8_t rte_v256s8_t __attribute__((vector_size(32),
+aligned(32)));
+
+/*
+ * 256 bits vector size to use with 16 bits elements.
+ * a = (rte_v256s16_t){ a00, a01, a02, a03, a04, a05, a06, a07,
+ * a08, a09, a10, a11, a12, a13, a14, a15 }
+ */
+typedef int16_t rte_v256s16_t __attribute__((vector_size(32),
+aligned(32)));
+
+/*
+ * 256 bits vector size to use with 32 bits elements.
+ * a = (rte_v256s32_t){ a0, a1, a2, a3, a4, a5, a6, a7 } */ typedef
+int32_t rte_v256s32_t __attribute__((vector_size(32), aligned(32)));
+
+/*
+ * 256 bits vector size to use with 64 bits elements.
+ * a = (rte_v256s64_t){ a0, a1, a2, a3 } */ typedef int64_t
+rte_v256s64_t __attribute__((vector_size(32), aligned(32)));
+
+#endif /* _RTE_VECT_H_ */
--
2.1.4
Acked-by: Chao Zhu < chaozhu@linux.vnet.ibm.com>
^ permalink raw reply related
* Re: [PATCH v3] maintainers: update testpmd maintainer
From: De Lara Guarch, Pablo @ 2016-11-29 8:49 UTC (permalink / raw)
To: Wu, Jingjing, dev@dpdk.org
In-Reply-To: <1480406330-46877-1-git-send-email-jingjing.wu@intel.com>
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Tuesday, November 29, 2016 7:59 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing; De Lara Guarch, Pablo
> Subject: [PATCH v3] maintainers: update testpmd maintainer
>
> Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Thanks Jingjing!
^ permalink raw reply
* [PATCH] doc: remove wrong document description
From: Baruch Siach @ 2016-11-29 9:25 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Baruch Siach
The Programmer’s Guide intro is not the Release Notes.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
doc/guides/prog_guide/intro.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/intro.rst b/doc/guides/prog_guide/intro.rst
index d6daab3763b4..9fe1f0c31f0e 100644
--- a/doc/guides/prog_guide/intro.rst
+++ b/doc/guides/prog_guide/intro.rst
@@ -44,7 +44,7 @@ Documentation Roadmap
The following is a list of DPDK documents in the suggested reading order:
-* **Release Notes** (this document): Provides release-specific information, including supported features,
+* **Release Notes** : Provides release-specific information, including supported features,
limitations, fixed issues, known issues and so on.
Also, provides the answers to frequently asked questions in FAQ format.
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 00/16] e1000 base code update
From: Thomas Monjalon @ 2016-11-29 9:28 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev, Yigit, Ferruh
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909393539B0@shsmsx102.ccr.corp.intel.com>
2016-11-29 00:30, Lu, Wenzhuo:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-11-25 12:58, Ferruh Yigit:
> > > Can you also please send another patch to:
> > > 1- add I219 to supported nics list
> > > 2- announce new supported nic in release notes.
> >
> > Please update also the web site:
> > http://dpdk.org/doc/nics
> Didn't know that. How to update it? Thanks.
Please check this repository:
http://dpdk.org/browse/tools/dpdk-web/
You can send a patch to this mailing list:
http://dpdk.org/ml/listinfo/web
^ permalink raw reply
* Re: [PATCH] doc: remove wrong document description
From: Mcnamara, John @ 2016-11-29 9:54 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <68dc5388c54099ba26e9d0d1dd30e5fa6f9fbfc0.1480411543.git.baruch@tkos.co.il>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, November 29, 2016 9:26 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH] doc: remove wrong document description
>
> The Programmer’s Guide intro is not the Release Notes.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Thanks for the fix.
I would be in favour of removing the entire "Documentation Roadmap" and "Related Publications" sections. I meant to do that in the past.
As for this patch:
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH 1/4] eventdev: introduce event driven programming model
From: Bruce Richardson @ 2016-11-29 10:00 UTC (permalink / raw)
To: Jerin Jacob
Cc: Thomas Monjalon, dev, harry.van.haaren, hemant.agrawal, gage.eads
In-Reply-To: <20161129040141.GA11674@svelivela-lt.caveonetworks.com>
On Tue, Nov 29, 2016 at 09:31:42AM +0530, Jerin Jacob wrote:
> On Mon, Nov 28, 2016 at 09:16:10AM +0000, Bruce Richardson wrote:
> > On Sat, Nov 26, 2016 at 08:24:55AM +0530, Jerin Jacob wrote:
> > > On Fri, Nov 25, 2016 at 11:00:53AM +0000, Bruce Richardson wrote:
> > > > On Fri, Nov 25, 2016 at 05:53:34AM +0530, Jerin Jacob wrote:
> > > > > On Thu, Nov 24, 2016 at 04:35:56PM +0100, Thomas Monjalon wrote:
> > > > > > 2016-11-24 07:29, Jerin Jacob:
> > > > > > > On Wed, Nov 23, 2016 at 07:39:09PM +0100, Thomas Monjalon wrote:
> > > > > > > > 2016-11-18 11:14, Jerin Jacob:
> > > > > > > > > +Eventdev API - EXPERIMENTAL
> > > > > > > > > +M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > > > > > > +F: lib/librte_eventdev/
> > > > > > > >
> > > > >
> > > > > I don't think there is any portability issue here, I can explain.
> > > > >
> > > > > The application level, we have two more use case to deal with non burst
> > > > > variant
> > > > >
> > > > > - latency critical work
> > > > > - on dequeue, if application wants to deal with only one flow(i.e to
> > > > > avoid processing two different application flows to avoid cache trashing)
> > > > >
> > > > > Selection of the burst variants will be based on
> > > > > rte_event_dev_info_get() and rte_event_dev_configure()(see, max_event_port_dequeue_depth,
> > > > > max_event_port_enqueue_depth, nb_event_port_dequeue_depth, nb_event_port_enqueue_depth )
> > > > > So I don't think their is portability issue here and I don't want to waste my
> > > > > CPU cycles on the for loop if application known to be working with non
> > > > > bursts variant like below
> > > > >
> > > >
> > > > If the application is known to be working on non-burst varients, then
> > > > they always request a burst-size of 1, and skip the loop completely.
> > > > There is no extra performance hit in that case in either the app or the
> > > > driver (since the non-burst driver always returns 1, irrespective of the
> > > > number requested).
> > >
> > > Hmm. I am afraid, There is.
> > > On the app side, the const "1" can not be optimized by the compiler as
> > > on downside it is function pointer based driver interface
> > > On the driver side, the implementation would be for loop based instead
> > > of plain access.
> > > (compiler never can see the const "1" in driver interface)
> > >
> > > We are planning to implement burst mode as kind of emulation mode and
> > > have a different scheme for burst and nonburst. The similar approach we have
> > > taken in introducing rte_event_schedule() and split the responsibility so
> > > that SW driver can work without additional performance overhead and neat
> > > driver interface.
> > >
> > > If you are concerned about the usability part and regression on the SW
> > > driver, then it's not the case, application will use nonburst variant only if
> > > dequeue_depth == 1 and/or explicit case where latency matters.
> > >
> > > On the portability side, we support both case and application if written based
> > > on dequeue_depth it will perform well in both implementations.IMO, There is
> > > no another shortcut for performance optimized application running on different
> > > set of model.I think it is not an issue as, in event model as each cores
> > > identical and main loop can be changed based on dequeue_depth
> > > if needs performance(anyway mainloop will be function pointer based).
> > >
> >
> > Ok, I think I see your point now. Here is an alternative suggestion.
> >
> > 1. Keep the single user API.
> > 2. Have both single and burst function pointers in the driver
> > 3. Call appropriately in the eventdev layer based on parameters. For
> > example:
> >
> > rte_event_dequeue_burst(..., int num)
> > {
> > if (num == 1 && single_dequeue_fn != NULL)
> > return single_dequeue_fn(...);
> > return burst_dequeue_fn(...);
> > }
> >
> > This way drivers can optionally special-case the single dequeue case -
> > the function pointer check will definitely be predictable in HW making
> > that a near-zero-cost check - while not forcing all drivers to do so.
> > It also reduces the public API surface, and gives us a single enqueue
> > and dequeue function.
>
> The alternative suggestion looks good to me. Yes, it makes sense to reduces the
> public API interface if possible.
>
> Regarding the implementation, I thought to have a bit approach like below
> to reduce the cost of additional AND operation.(with const "1", compiler
> can choose with correct one with out any overhead)
>
> rte_event_dequeue_burst(..., int num)
> {
> if (num == 1)
> return single_dequeue_fn(...);
> return burst_dequeue_fn(...);
> }
>
> "single_dequeue_fn" populated from the driver layer.
> In the absence of populating the "single_dequeue_fn" from the driver layer,
> The common code can create the single_dequeue_fn using driver
> provided "burst_dequeue_fn"
>
> something like
> generic_single_dequeue_fn(dev){
> {
> dev->burst_dequeue_fn(..,1);
> }
>
> Any concerns?
>
No, works ok for me
/Bruce
^ permalink raw reply
* Re: [PATCH] doc: introduce PVP reference benchmark
From: Yuanhan Liu @ 2016-11-29 10:16 UTC (permalink / raw)
To: Maxime Coquelin
Cc: thomas.monjalon, john.mcnamara, zhiyong.yang, dev, fbaudin
In-Reply-To: <f9f4f377-5fa2-3f9e-76af-a26e3b852de0@redhat.com>
On Thu, Nov 24, 2016 at 08:35:51AM +0100, Maxime Coquelin wrote:
>
>
> On 11/24/2016 06:07 AM, Yuanhan Liu wrote:
> >First of all, thanks for the doc! It's a great one.
> Thanks.
> I would be interested to know if you have other tuning I don't mention
> in this doc.
I was thinking we may need doc some performance impacts by some features,
say we observed that indirect desc may be good for some cases, while may
be bad for others. Also, the non mergeable Rx path outweighs the mergeable
Rx path. If user cares about the perfomance and ascertains all packets
fits into a typical MTU, he may likely want to disable the mergeable
feature, which is enabled by default.
Maybe we could start a new doc, or maybe we could add a new section here?
--yliu
^ permalink raw reply
* [PATCH] doc: fix typos in code comments
From: Yong Wang @ 2016-11-29 22:23 UTC (permalink / raw)
To: olivier.matz; +Cc: dev, Yong Wang
Signed-off-by: Yong Wang <wang.yong19@zte.com.cn>
---
lib/librte_mempool/rte_mempool.h | 2 +-
lib/librte_ring/rte_ring.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 440f3b1..c221333 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -551,7 +551,7 @@ struct rte_mempool_ops_table {
/**
* Macro to statically register the ops of a mempool handler.
* Note that the rte_mempool_register_ops fails silently here when
- * more then RTE_MEMPOOL_MAX_OPS_IDX is registered.
+ * more than RTE_MEMPOOL_MAX_OPS_IDX is registered.
*/
#define MEMPOOL_REGISTER_OPS(ops) \
void mp_hdlr_init_##ops(void); \
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 32b8c8d..e359aff 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -106,7 +106,7 @@
enum rte_ring_queue_behavior {
RTE_RING_QUEUE_FIXED = 0, /* Enq/Deq a fixed number of items from a ring */
- RTE_RING_QUEUE_VARIABLE /* Enq/Deq as many items a possible from ring */
+ RTE_RING_QUEUE_VARIABLE /* Enq/Deq as many items as possible from ring */
};
#ifdef RTE_LIBRTE_RING_DEBUG
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] doc: fix typos in code comments
From: Mcnamara, John @ 2016-11-29 10:23 UTC (permalink / raw)
To: Yong Wang, olivier.matz@6wind.com; +Cc: dev@dpdk.org
In-Reply-To: <201611291017.uATAHj6q082558@mse01.zte.com.cn>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yong Wang
> Sent: Tuesday, November 29, 2016 10:24 PM
> To: olivier.matz@6wind.com
> Cc: dev@dpdk.org; Yong Wang <wang.yong19@zte.com.cn>
> Subject: [dpdk-dev] [PATCH] doc: fix typos in code comments
>
> Signed-off-by: Yong Wang <wang.yong19@zte.com.cn>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH] doc: introduce PVP reference benchmark
From: Maxime Coquelin @ 2016-11-29 10:29 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: thomas.monjalon, john.mcnamara, zhiyong.yang, dev, fbaudin
In-Reply-To: <20161129101647.GP5048@yliu-dev.sh.intel.com>
Hi Yuanhan,
On 11/29/2016 11:16 AM, Yuanhan Liu wrote:
> On Thu, Nov 24, 2016 at 08:35:51AM +0100, Maxime Coquelin wrote:
>>
>>
>> On 11/24/2016 06:07 AM, Yuanhan Liu wrote:
>>> First of all, thanks for the doc! It's a great one.
>> Thanks.
>> I would be interested to know if you have other tuning I don't mention
>> in this doc.
>
> I was thinking we may need doc some performance impacts by some features,
> say we observed that indirect desc may be good for some cases, while may
> be bad for others. Also, the non mergeable Rx path outweighs the mergeable
> Rx path. If user cares about the perfomance and ascertains all packets
> fits into a typical MTU, he may likely want to disable the mergeable
> feature, which is enabled by default.
>
> Maybe we could start a new doc, or maybe we could add a new section here?
I agree that we should documents impact of Virtio features on traffic
profile.
My opinion is that it deserves a dedicated document.
For this PVP doc, I suggest we add a section stating that one could try
with different Virtio features, and in Kevin's result template
proposal, we add a line for Virtio features enabled/disabled.
Thanks,
Maxime
>
> --yliu
>
^ permalink raw reply
* Re: [PATCH] doc: remove wrong document description
From: Baruch Siach @ 2016-11-29 10:54 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20266AAB8@IRSMSX103.ger.corp.intel.com>
Hi John,
On Tue, Nov 29, 2016 at 09:54:58AM +0000, Mcnamara, John wrote:
> > -----Original Message-----
> > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > Sent: Tuesday, November 29, 2016 9:26 AM
> > To: dev@dpdk.org
> > Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> > <baruch@tkos.co.il>
> > Subject: [PATCH] doc: remove wrong document description
> >
> > The Programmer’s Guide intro is not the Release Notes.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>
> Thanks for the fix.
>
> I would be in favour of removing the entire "Documentation Roadmap" and
> "Related Publications" sections. I meant to do that in the past.
>
> As for this patch:
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Thanks. For some reason patchwork didn't get your ack.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH v3] maintainers: update testpmd maintainer
From: Thomas Monjalon @ 2016-11-29 10:54 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: dev, De Lara Guarch, Pablo
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA3D2DC@IRSMSX108.ger.corp.intel.com>
> > Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
>
> Thanks Jingjing!
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] doc: remove wrong document description
From: Mcnamara, John @ 2016-11-29 10:58 UTC (permalink / raw)
To: Baruch Siach; +Cc: dev@dpdk.org
In-Reply-To: <20161129105421.lzcgiuygbbjabaur@tarshish>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, November 29, 2016 10:54 AM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] doc: remove wrong document description
>
> Hi John,
>
> On Tue, Nov 29, 2016 at 09:54:58AM +0000, Mcnamara, John wrote:
> > > -----Original Message-----
> > > From: Baruch Siach [mailto:baruch@tkos.co.il]
> > > Sent: Tuesday, November 29, 2016 9:26 AM
> > > To: dev@dpdk.org
> > > Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> > > <baruch@tkos.co.il>
> > > Subject: [PATCH] doc: remove wrong document description
> > >
> > > The Programmer’s Guide intro is not the Release Notes.
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> >
> > Thanks for the fix.
> >
> > I would be in favour of removing the entire "Documentation Roadmap"
> > and "Related Publications" sections. I meant to do that in the past.
> >
> > As for this patch:
> >
> > Acked-by: John McNamara <john.mcnamara@intel.com>
>
> Thanks. For some reason patchwork didn't get your ack.
Strange. I worked for one I acked shortly afterwards.
I'll try once more.
John
^ permalink raw reply
* Re: [PATCH RFC 1/2] net/i40e: allow bulk alloc for the max size desc ring
From: Ilya Maximets @ 2016-11-29 10:59 UTC (permalink / raw)
To: dev, Helin Zhang, Konstantin Ananyev, Jingjing Wu
Cc: Dyasly Sergey, Heetae Ahn, Bruce Richardson, Ferruh Yigit
In-Reply-To: <1476886037-4586-2-git-send-email-i.maximets@samsung.com>
Ping.
Best regards, Ilya Maximets.
On 19.10.2016 17:07, Ilya Maximets wrote:
> The only reason why bulk alloc disabled for the rings with
> more than (I40E_MAX_RING_DESC - RTE_PMD_I40E_RX_MAX_BURST)
> descriptors is the possible out-of-bound access to the dma
> memory. But it's the artificial limit and can be easily
> avoided by allocating of RTE_PMD_I40E_RX_MAX_BURST more
> descriptors in memory. This will not interfere the HW and,
> as soon as all rings' memory zeroized, Rx functions will
> work correctly.
>
> This change allows to use vectorized Rx functions with
> 4096 descriptors in Rx ring which is important to achieve
> zero packet drop rate in high-load installations.
>
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> ---
> drivers/net/i40e/i40e_rxtx.c | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 7ae7d9f..1f76691 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -409,15 +409,6 @@ check_rx_burst_bulk_alloc_preconditions(__rte_unused struct i40e_rx_queue *rxq)
> "rxq->rx_free_thresh=%d",
> rxq->nb_rx_desc, rxq->rx_free_thresh);
> ret = -EINVAL;
> - } else if (!(rxq->nb_rx_desc < (I40E_MAX_RING_DESC -
> - RTE_PMD_I40E_RX_MAX_BURST))) {
> - PMD_INIT_LOG(DEBUG, "Rx Burst Bulk Alloc Preconditions: "
> - "rxq->nb_rx_desc=%d, "
> - "I40E_MAX_RING_DESC=%d, "
> - "RTE_PMD_I40E_RX_MAX_BURST=%d",
> - rxq->nb_rx_desc, I40E_MAX_RING_DESC,
> - RTE_PMD_I40E_RX_MAX_BURST);
> - ret = -EINVAL;
> }
> #else
> ret = -EINVAL;
> @@ -1698,8 +1689,19 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
> rxq->rx_deferred_start = rx_conf->rx_deferred_start;
>
> /* Allocate the maximun number of RX ring hardware descriptor. */
> - ring_size = sizeof(union i40e_rx_desc) * I40E_MAX_RING_DESC;
> - ring_size = RTE_ALIGN(ring_size, I40E_DMA_MEM_ALIGN);
> + len = I40E_MAX_RING_DESC;
> +
> +#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
> + /**
> + * Allocating a little more memory because vectorized/bulk_alloc Rx
> + * functions doesn't check boundaries each time.
> + */
> + len += RTE_PMD_I40E_RX_MAX_BURST;
> +#endif
> +
> + ring_size = RTE_ALIGN(len * sizeof(union i40e_rx_desc),
> + I40E_DMA_MEM_ALIGN);
> +
> rz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
> ring_size, I40E_RING_BASE_ALIGN, socket_id);
> if (!rz) {
>
^ permalink raw reply
* Re: [PATCH RFC 2/2] net/ixgbe: allow bulk alloc for the max size desc ring
From: Ilya Maximets @ 2016-11-29 10:59 UTC (permalink / raw)
To: dev, Helin Zhang, Konstantin Ananyev, Jingjing Wu
Cc: Dyasly Sergey, Heetae Ahn, Bruce Richardson
In-Reply-To: <1476886037-4586-3-git-send-email-i.maximets@samsung.com>
Ping.
Best regards, Ilya Maximets.
On 19.10.2016 17:07, Ilya Maximets wrote:
> The only reason why bulk alloc disabled for the rings with
> more than (IXGBE_MAX_RING_DESC - RTE_PMD_IXGBE_RX_MAX_BURST)
> descriptors is the possible out-of-bound access to the dma
> memory. But it's the artificial limit and can be easily
> avoided by allocating of RTE_PMD_IXGBE_RX_MAX_BURST more
> descriptors in memory. This will not interfere the HW and,
> as soon as all rings' memory zeroized, Rx functions will
> work correctly.
>
> This change allows to use vectorized Rx functions with
> 4096 descriptors in Rx ring which is important to achieve
> zero packet drop rate in high-load installations.
>
> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> ---
> drivers/net/ixgbe/ixgbe_rxtx.c | 17 +----------------
> drivers/net/ixgbe/ixgbe_rxtx.h | 2 +-
> 2 files changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 2ce8234..07c04c3 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -2585,7 +2585,6 @@ check_rx_burst_bulk_alloc_preconditions(struct ixgbe_rx_queue *rxq)
> * rxq->rx_free_thresh >= RTE_PMD_IXGBE_RX_MAX_BURST
> * rxq->rx_free_thresh < rxq->nb_rx_desc
> * (rxq->nb_rx_desc % rxq->rx_free_thresh) == 0
> - * rxq->nb_rx_desc<(IXGBE_MAX_RING_DESC-RTE_PMD_IXGBE_RX_MAX_BURST)
> * Scattered packets are not supported. This should be checked
> * outside of this function.
> */
> @@ -2607,15 +2606,6 @@ check_rx_burst_bulk_alloc_preconditions(struct ixgbe_rx_queue *rxq)
> "rxq->rx_free_thresh=%d",
> rxq->nb_rx_desc, rxq->rx_free_thresh);
> ret = -EINVAL;
> - } else if (!(rxq->nb_rx_desc <
> - (IXGBE_MAX_RING_DESC - RTE_PMD_IXGBE_RX_MAX_BURST))) {
> - PMD_INIT_LOG(DEBUG, "Rx Burst Bulk Alloc Preconditions: "
> - "rxq->nb_rx_desc=%d, "
> - "IXGBE_MAX_RING_DESC=%d, "
> - "RTE_PMD_IXGBE_RX_MAX_BURST=%d",
> - rxq->nb_rx_desc, IXGBE_MAX_RING_DESC,
> - RTE_PMD_IXGBE_RX_MAX_BURST);
> - ret = -EINVAL;
> }
>
> return ret;
> @@ -2632,12 +2622,7 @@ ixgbe_reset_rx_queue(struct ixgbe_adapter *adapter, struct ixgbe_rx_queue *rxq)
> /*
> * By default, the Rx queue setup function allocates enough memory for
> * IXGBE_MAX_RING_DESC. The Rx Burst bulk allocation function requires
> - * extra memory at the end of the descriptor ring to be zero'd out. A
> - * pre-condition for using the Rx burst bulk alloc function is that the
> - * number of descriptors is less than or equal to
> - * (IXGBE_MAX_RING_DESC - RTE_PMD_IXGBE_RX_MAX_BURST). Check all the
> - * constraints here to see if we need to zero out memory after the end
> - * of the H/W descriptor ring.
> + * extra memory at the end of the descriptor ring to be zero'd out.
> */
> if (adapter->rx_bulk_alloc_allowed)
> /* zero out extra memory */
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
> index 2608b36..1abc6f2 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.h
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.h
> @@ -67,7 +67,7 @@
> #define RTE_IXGBE_MAX_RX_BURST RTE_IXGBE_RXQ_REARM_THRESH
> #endif
>
> -#define RX_RING_SZ ((IXGBE_MAX_RING_DESC + RTE_IXGBE_DESCS_PER_LOOP - 1) * \
> +#define RX_RING_SZ ((IXGBE_MAX_RING_DESC + RTE_PMD_IXGBE_RX_MAX_BURST) * \
> sizeof(union ixgbe_adv_rx_desc))
>
> #ifdef RTE_PMD_PACKET_PREFETCH
>
^ permalink raw reply
* Re: [PATCH] doc: remove wrong document description
From: Mcnamara, John @ 2016-11-29 10:59 UTC (permalink / raw)
To: Baruch Siach, dev@dpdk.org
In-Reply-To: <68dc5388c54099ba26e9d0d1dd30e5fa6f9fbfc0.1480411543.git.baruch@tkos.co.il>
> -----Original Message-----
> From: Baruch Siach [mailto:baruch@tkos.co.il]
> Sent: Tuesday, November 29, 2016 9:26 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Baruch Siach
> <baruch@tkos.co.il>
> Subject: [PATCH] doc: remove wrong document description
>
> The Programmer’s Guide intro is not the Release Notes.
>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH v1] maintainers: update procinfo maintainer
From: Thomas Monjalon @ 2016-11-29 11:09 UTC (permalink / raw)
To: John McNamara, reshma.pattan; +Cc: dev
In-Reply-To: <1479488966-30258-1-git-send-email-john.mcnamara@intel.com>
2016-11-18 17:09, John McNamara:
> Update procinfo maintainer and name of the application.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v1] maintainers: update lthreads maintainer
From: Thomas Monjalon @ 2016-11-29 11:11 UTC (permalink / raw)
To: John McNamara; +Cc: dev
In-Reply-To: <1479488991-30432-1-git-send-email-john.mcnamara@intel.com>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
[...]
> -M: Ian Betts <ian.betts@intel.com>
> +M: John McNamara <john.mcnamara@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Applied, thanks
We need to talk about the status of this library.
^ permalink raw reply
* Re: [PATCH RFC 1/2] net/i40e: allow bulk alloc for the max size desc ring
From: Ananyev, Konstantin @ 2016-11-29 12:50 UTC (permalink / raw)
To: Ilya Maximets, dev@dpdk.org, Zhang, Helin, Wu, Jingjing
Cc: Dyasly Sergey, Heetae Ahn, Richardson, Bruce, Yigit, Ferruh
In-Reply-To: <0b31fd94-d5b2-acb8-8d55-a6fe124c9886@samsung.com>
Hi Ilya,
> Ping.
>
> Best regards, Ilya Maximets.
>
> On 19.10.2016 17:07, Ilya Maximets wrote:
> > The only reason why bulk alloc disabled for the rings with
> > more than (I40E_MAX_RING_DESC - RTE_PMD_I40E_RX_MAX_BURST)
> > descriptors is the possible out-of-bound access to the dma
> > memory. But it's the artificial limit and can be easily
> > avoided by allocating of RTE_PMD_I40E_RX_MAX_BURST more
> > descriptors in memory. This will not interfere the HW and,
> > as soon as all rings' memory zeroized, Rx functions will
> > work correctly.
> >
> > This change allows to use vectorized Rx functions with
> > 4096 descriptors in Rx ring which is important to achieve
> > zero packet drop rate in high-load installations.
> >
> > Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> > ---
> > drivers/net/i40e/i40e_rxtx.c | 24 +++++++++++++-----------
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> > index 7ae7d9f..1f76691 100644
> > --- a/drivers/net/i40e/i40e_rxtx.c
> > +++ b/drivers/net/i40e/i40e_rxtx.c
> > @@ -409,15 +409,6 @@ check_rx_burst_bulk_alloc_preconditions(__rte_unused struct i40e_rx_queue *rxq)
> > "rxq->rx_free_thresh=%d",
> > rxq->nb_rx_desc, rxq->rx_free_thresh);
> > ret = -EINVAL;
> > - } else if (!(rxq->nb_rx_desc < (I40E_MAX_RING_DESC -
> > - RTE_PMD_I40E_RX_MAX_BURST))) {
> > - PMD_INIT_LOG(DEBUG, "Rx Burst Bulk Alloc Preconditions: "
> > - "rxq->nb_rx_desc=%d, "
> > - "I40E_MAX_RING_DESC=%d, "
> > - "RTE_PMD_I40E_RX_MAX_BURST=%d",
> > - rxq->nb_rx_desc, I40E_MAX_RING_DESC,
> > - RTE_PMD_I40E_RX_MAX_BURST);
> > - ret = -EINVAL;
> > }
> > #else
> > ret = -EINVAL;
> > @@ -1698,8 +1689,19 @@ i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
> > rxq->rx_deferred_start = rx_conf->rx_deferred_start;
> >
> > /* Allocate the maximun number of RX ring hardware descriptor. */
> > - ring_size = sizeof(union i40e_rx_desc) * I40E_MAX_RING_DESC;
> > - ring_size = RTE_ALIGN(ring_size, I40E_DMA_MEM_ALIGN);
> > + len = I40E_MAX_RING_DESC;
> > +
> > +#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
> > + /**
> > + * Allocating a little more memory because vectorized/bulk_alloc Rx
> > + * functions doesn't check boundaries each time.
> > + */
> > + len += RTE_PMD_I40E_RX_MAX_BURST;
> > +#endif
> > +
Looks good to me.
One question, though do we really need '+#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC' here?
Why just not remove this ifdef here and always add allocate extra descriptors.
Konstantin
> > + ring_size = RTE_ALIGN(len * sizeof(union i40e_rx_desc),
> > + I40E_DMA_MEM_ALIGN);
> > +
> > rz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
> > ring_size, I40E_RING_BASE_ALIGN, socket_id);
> > if (!rz) {
> >
^ 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