[dpdk-dev] [PATCH] fix build on Atom without SSE4 support
I'm buiding dpdk on an N2600 Cedarview Atom, using gcc 4.9.2 on Fedora 21. At least one instruction in the optimized version of rte_sched::grinder_pipe_exists (_mm_testz_si128) requires SSE4. Mike Sowka (1): sched: fix build on Atom without SSE4 support lib/librte_sched/rte_sched.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.1.0
[dpdk-dev] [PATCH] sched: fix build on Atom without SSE4 support
--- lib/librte_sched/rte_sched.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c index 21ebf25..6f92aa6 100644 --- a/lib/librte_sched/rte_sched.c +++ b/lib/librte_sched/rte_sched.c @@ -55,8 +55,8 @@ #ifdef RTE_SCHED_VECTOR #include -#if defined(__SSE2__) -#define SCHED_VECTOR_SSE2 +#if defined(__SSE4__) +#define SCHED_VECTOR_SSE4 #endif #endif @@ -1672,7 +1672,7 @@ grinder_schedule(struct rte_sched_port *port, uint32_t pos) return 1; } -#ifdef SCHED_VECTOR_SSE2 +#ifdef SCHED_VECTOR_SSE4 static inline int grinder_pipe_exists(struct rte_sched_port *port, uint32_t base_pipe) -- 2.1.0
[dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
-Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Friday, December 4, 2015 6:34 PM To: Stephen Hemminger Cc: dev at dpdk.org; Betts, Ian Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread 2015-12-04 10:03, Stephen Hemminger: > Looks useful, but this needs more discussion. > > Maybe it should be a separate library not tied into DPDK so it gets > wider use and testing? Also what are the limitations? > What if an lthread did a system call? What about interaction with > rte_poll? > > Earlier attempts at lightweight threading (fibers) would be worth > looking into. http://c2.com/cgi/wiki?CooperativeThreading > Intel Thread Building Blocks > IBM NGPT (now defunct) > > There lots of hidden gotcha's here, like preemption (or not), and > limitations on interactions with other libraries. > > Intel may have some milestone to get it into DPDK 2.2 but really this > seems too late... >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe. Just to understand what we mean by too late... The original RFC was issued on 2nd September. Thus there have been some three months available for discussion, and for people to raise any questions or concerns. The first patch was available on 30th September, and a number of subsequent patch versions have been issued, meaning the code has been available for review for two months. As mentioned in the reply to Stephen, there has been no adverse feedback during this period. /Ian
[dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
-Original Message- From: Betts, Ian Sent: Saturday, December 5, 2015 12:07 PM To: Thomas Monjalon; Stephen Hemminger Cc: dev at dpdk.org; O'Driscoll, Tim; Richardson, Bruce; Glynn, Michael J Subject: RE: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Friday, December 4, 2015 6:34 PM To: Stephen Hemminger Cc: dev at dpdk.org; Betts, Ian Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread > Intel may have some milestone to get it into DPDK 2.2 but really this > seems too late... >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe >Just to understand what we mean by too late... >The original RFC was issued on 2nd September. >Thus there have been some three months available for discussion, and for >people to raise any questions or concerns. >The first patch was available on 30th September, and a number of subsequent >patch versions have been issued, meaning the code has been available for >review for two month >As mentioned in the reply to Stephen, there has been no adverse feedback >during this period. >/Ian Hi Thomas/Stephen I agree with Ian, how much time is expected for a discussion to happen? As Ian stated, the feature was stated in our 2.2 planned feature list, we created a RFC over 3 months ago, and there's been code available for review for over 2 months now! (not to mention several version updates, docs, etc.). Given this, I believe that there has been ample time for the community to review and provide feedback rather than waiting until the eve of RC3 and then requesting more time. In addition, by making it a sample application first people can test it, see if it's useful, and further enhance it. Based on usefulness and feedback, we can then decide whether to make it a DPDK library in a future release, make it a separate library somewhere else, or do nothing further on it For these reasons, I believe it should be merged into RC3 Regards Mike
[dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
On Sat, 5 Dec 2015 17:53:04 + "Glynn, Michael J" wrote: > > > -Original Message- > From: Betts, Ian > Sent: Saturday, December 5, 2015 12:07 PM > To: Thomas Monjalon; Stephen Hemminger > Cc: dev at dpdk.org; O'Driscoll, Tim; Richardson, Bruce; Glynn, Michael J > Subject: RE: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread > > > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, December 4, 2015 6:34 PM > To: Stephen Hemminger > Cc: dev at dpdk.org; Betts, Ian > Subject: Re: [dpdk-dev] [PATCH v8 0/4] examples: add performance-thread > > > Intel may have some milestone to get it into DPDK 2.2 but really this > > seems too late... > > >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe > >Just to understand what we mean by too late... > >The original RFC was issued on 2nd September. > >Thus there have been some three months available for discussion, and for > >people to raise any questions or concerns. > >The first patch was available on 30th September, and a number of subsequent > >patch versions have been issued, meaning the code has been available for > >review for two month > >As mentioned in the reply to Stephen, there has been no adverse feedback > >during this period. > >/Ian > > Hi Thomas/Stephen > > I agree with Ian, how much time is expected for a discussion to happen? > > As Ian stated, the feature was stated in our 2.2 planned feature list, we > created a RFC over 3 months ago, and there's been code available for review > for over 2 months now! (not to mention several version updates, docs, etc.). > Given this, I believe that there has been ample time for the community to > review and provide feedback rather than waiting until the eve of RC3 and then > requesting more time. > > In addition, by making it a sample application first people can test it, see > if it's useful, and further enhance it. Based on usefulness and feedback, we > can then decide whether to make it a DPDK library in a future release, make > it a separate library somewhere else, or do nothing further on it > > For these reasons, I believe it should be merged into RC3 Since it is an example and well documented that is fine. Is there an explicit statement that ABI is not binding for examples?
[dpdk-dev] [PATCH] sched: fix build on Atom without SSE4 support
2015-12-05 00:00, Mike Sowka: > --- > lib/librte_sched/rte_sched.c | 6 +++--- Please provide some explanations and Signed-off. No cover letter is needed for one patch. Guide of patch submission here: http://dpdk.org/dev#send Thanks
[dpdk-dev] [PATCH v8 0/4] examples: add performance-thread
> > > Intel may have some milestone to get it into DPDK 2.2 but really this > > > seems too late... > > > > >>>Yes, sure it is too late to have enough discussions in 2.2 timeframe > > >Just to understand what we mean by too late... > > >The original RFC was issued on 2nd September. > > >Thus there have been some three months available for discussion, and for > > >people to raise any questions or concerns. > > >The first patch was available on 30th September, and a number of > > >subsequent patch versions have been issued, meaning the code has been > > >available for review for two month > > >As mentioned in the reply to Stephen, there has been no adverse feedback > > >during this period. > > >/Ian > > > > Hi Thomas/Stephen > > > > I agree with Ian, how much time is expected for a discussion to happen? > > > > As Ian stated, the feature was stated in our 2.2 planned feature list, we > > created a RFC over 3 months ago, and there's been code available for review > > for over 2 months now! (not to mention several version updates, docs, > > etc.). > > Given this, I believe that there has been ample time for the community to > > review and provide feedback rather than waiting until the eve of RC3 and > > then requesting more time. > > > > In addition, by making it a sample application first people can test it, > > see if it's useful, and further enhance it. Based on usefulness and > > feedback, we can then decide whether to make it a DPDK library in a future > > release, make it a separate library somewhere else, or do nothing further > > on it > > > > For these reasons, I believe it should be merged into RC3 I am not against this idea. I just say that we have no time anymore for discussions. There was no review probably because it is "just" an example. Given that the code is huge, it would be better to have some good feedback for its integration. But it does not hurt to integrate anyway. The only problem is the maintenance overload. When we change something in a library, every examples must be updated to keep them working. That's why we must avoid keeping some useless examples. So this one must be discussed during the 2.3 cycle and will see if we keep it, shrink it, revert it or move to a library. > Since it is an example and well documented that is fine. > Is there an explicit statement that ABI is not binding for examples? What do you mean by "binding"?
[dpdk-dev] [PATCH] sched: fix build on Atom without SSE4 support
Thanks for the pointers Thomas. Here is a signed-off patch re-submission with some explanation, to the best of my experience. Irrelevant of the target, the preprocessor #ifdef SSE2 for the grinder_pipe_exists function is inadequate since the __mm_testz_si128 function requires SSE4.1, PTEST instruction described in https://en.wikipedia.org/wiki/SSE4#SSE4.1 (I do no have better spec reference). I have bumped the preprocessor #ifdef to require SSE4. The Atom N2600 does not have SSE4, http://ark.intel.com/products/58916, and so I had trouble building rte_sched with optimized version of grinder_pipe_exists, with following: error: inlining failed in call to always_inline _mm_testz_si128?: target specific option mismatch GCC 4.9 correctly identifies my target as not having SSE4, and with provided patch builds the non-optimized version of grinder_pipe_exists. Signed-off-by: Mike Sowka --- lib/librte_sched/rte_sched.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c index 21ebf25..6f92aa6 100644 --- a/lib/librte_sched/rte_sched.c +++ b/lib/librte_sched/rte_sched.c @@ -55,8 +55,8 @@ #ifdef RTE_SCHED_VECTOR #include -#if defined(__SSE2__) -#define SCHED_VECTOR_SSE2 +#if defined(__SSE4__) +#define SCHED_VECTOR_SSE4 #endif #endif @@ -1672,7 +1672,7 @@ grinder_schedule(struct rte_sched_port *port, uint32_t pos) return 1; } -#ifdef SCHED_VECTOR_SSE2 +#ifdef SCHED_VECTOR_SSE4 static inline int grinder_pipe_exists(struct rte_sched_port *port, uint32_t base_pipe) -- 2.1.0
[dpdk-dev] librte_power w/ intel_pstate cpufreq governor
Hello all, I wanted to ask some questions about librte_power and the great adaptive polling / IRQ mode example in l3fwd-power. I am very interested in getting this to work in my project because it will make it much friendlier to attract new community developers if I am as cooperative as possible with system resources. Let's discuss the init process for a moment. It has some problems on my system, and I need some help to figure out how to handle this right. 1. Begins with the call to rte_power_init. 2. Attempts to init ACPI cpufreq mode. 2.1. Sets lcore cpufreq governor to userspace mode. 2.2. Function power_get_available_freqs checks lcore CPU frequencies from: /sys/devices/system/cpu/cpuX/cpufreq/scaling_available_frequencies 2.3. This fails with (cryptic) error "POWER: ERR: File not openned". I am planning to write a patch for this error a bit later. My kernel is using the intel_pstate driver, so scaling_available_frequencies does not exist: http://askubuntu.com/questions/544266/why-are-missing-the-frequency-options-on-cpufreq-utils-indicator 3. When power_get_available_freqs fails, rte_power_acpi_cpufreq_init fails. 4. rte_power_init will try rte_power_kvm_vm_init. That will fail because it's a physical Skylake system not some kind of VM. 5. Now rte_power_init totally fails, with error "POWER: ERR: Unable to set Power Management Environment for lcore 0". So, I have a couple of questions to figure out from here: 1. It seems bad to switch the governor into userspace before verifying the frequencies available in scaling_available_frequencies. If there are no frequencies available, it seems like it should not be trying to take over control of an effectively uncontrollable value. 2. If the governor is switched to userspace, and then no governing is done, it seems like the clockrate will necessarily always be wrong also because nothing will be configuring it anymore, neither kernel, nor failed DPDK userspace code, since rte_power_freq_up / down function pointers will always be NULL. Is this true? This seems bad if so. It seems that the librte_power code is basically out of date, as pstate has been present since Sandy Bridge, which is quite old by now for network processing. I am not sure how to make this work right now. So far I see a couple options but I really don't know much about this stuff: 1) skip rte_power_init completely, and let intel_pstate handle it using HWP mode 2) disable intel_pstate, switch to the legacy ACPI cpufreq (but people warned this old driver is mostly a no-op and the CPU ignores its frequency requests). The Internet advice says it's possible, but not a very good idea, to switch from the modern intel_pstate driver to the legacy ACPI mode. Reading through the kernel docs (below) state that it's better to use HWP (Hardware P State) mode: https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt If none of this rte_power_init stuff works, are the other CPU conservation measures inside the l3fwd-power example enough to work right with HWP all by themselves with nothing additional? Thanks, Matthew.
[dpdk-dev] [PATCH 2/2] virtio: clean up space checks on xmit
int error;
> >
> > @@ -846,58 +845,49 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf
> > **tx_pkts, uint16_t nb_pkts)
> > if (likely(nb_used > txvq->vq_nentries - txvq->vq_free_thresh))
> > virtio_xmit_cleanup(txvq, nb_used);
> >
> > - nb_tx = 0;
> > -
> > - while (nb_tx < nb_pkts) {
> > + for (nb_tx = 0; nb_tx < nb_pkts; nb_tx++) {
> > + struct rte_mbuf *txm = tx_pkts[nb_tx];
> > /* Need one more descriptor for virtio header. */
> > - int need = tx_pkts[nb_tx]->nb_segs - txvq->vq_free_cnt + 1;
> > + int need = txm->nb_segs - txvq->vq_free_cnt + 1;
>
> While reviewing the code, I found the var name `need' is not properly
> taken. Maybe `need_cleanup' is better, and it's better to be defined
> as bool type. What do you think of that?
The variable need indicates how many more buffers are needed to
complete the transmit. In later patches, there is a variable slots
so:
needed = slots - free
So if needed is positive, then more buffers are needed than available
and transmit is blocked. If needed is negative then there is free
space available.
>
> (And yes, it has nothing to do with your patch, I just found it we
> can rename it to a better name to improve the code readability a bit.
> If you agree, would you submit a patch, or should I do it?)
>
> >
> > - /*Positive value indicates it need free vring descriptors */
> > + /* Positive value indicates it need free vring descriptors */
> > if (unlikely(need > 0)) {
> > nb_used = VIRTQUEUE_NUSED(txvq);
> > virtio_rmb();
> > need = RTE_MIN(need, (int)nb_used);
> >
> > virtio_xmit_cleanup(txvq, need);
> > - need = (int)tx_pkts[nb_tx]->nb_segs -
> > - txvq->vq_free_cnt + 1;
> > + need = txm->nb_segs - txvq->vq_free_cnt + 1;
> > + if (unlikely(need > 0)) {
> > + PMD_TX_LOG(ERR,
> > + "No free tx descriptors to
> > transmit");
> > + break;
> > + }
>^
>
> Minor nit: I found a leading white space there.
Hmm. I didn't see it in checkpatch.
