> +#ifdef RTE_EXEC_ENV_BAREMETAL
>>+#define MAIN _main
>>+#else
>>+#define MAIN main
>>+#endif
>>+
>>+int MAIN(int argc, char *argv[]);
>>+
>>+#endif /* ifndef_MAIN_H_ */
why keeping the baremetal? It was dropped for a while.
Best regards,
Vincent
librte_pmd_pcap
http://dpdk.org/browse/dpdk/tree/lib/librte_pmd_pcap
On 06/03/2014 22:25, Neil Horman wrote:
> Hey there-
> I'm interested in doing some work on the DPDK, specifically in creating
> a driver backend that interfaces to the kernel using AF_PACKET rather than a
> specific car
On 02/05/2014 11:00, Burakov, Anatoly wrote:
> Hi Chris,
>
>> hmm, vfio requires iommu support, however virtio pmd?
>
> That's correct, virtio will not work with VFIO as it stands. However it's not
> the fault of this patch but rather lack of emulated IOMMU on the guest :-)
My 2 cents:
http://
Neil,
> Please find here:
> http://people.redhat.com/nhorman/dpdk-1.7.0-0.1.gitb20539d68.src.rpm
Your spec file is broken:
A simple patch:
--- dpdk.spec 2014-05-13 22:43:15.89200 +
+++ ../dpdk.spec.vj 2014-05-13 22:42:40.22100 +
@@ -75,7 +75,7 @@
%build
make O=%{ta
+1 for hangout
Le 1 nov. 2014 13:59, "Neil Horman" a ?crit :
> On Fri, Oct 31, 2014 at 05:36:59PM +, O'driscoll, Tim wrote:
> > Thanks again to those who attended the call earlier. Hopefully people
> found it useful.
> >
> > We'll schedule a follow-up call for 2 weeks' time. One thing that we
Stephen,
According to Dave (cc'd): it cannot be applied for FOSDEM; the
organizers would not be happy if we proposed that.
Best regards,
Vincent
On 01/11/2014 22:43, Stephen Hemminger wrote:
> Rather than individual talks what about getting them to schedule a 1/2 day
> unconference?
>
> On F
+Or
On 05/11/2014 23:48, Zhou, Danny wrote:
> Hi Thomas,
>
> Thanks for sharing the links to ibverbs, I will take a close look at it and
> compare it to bifurcated driver. My take
> after a rough review is that idea is very much similar, but bifurcated driver
> implementation is generic for any
On 19/07/2013 16:30, Antti Kantee wrote:
> Semi-related: why does DPDK take a blacklist instead of a list of
> devices that it should use (perhaps with a special value "all" in case
> someone really wants that behavior)? Historical reasons?
>
> (yes, I've also bricked my ssh connections several ti
it is just look n feel, just push it.
Acked-by: vincent.jardin at 6wind.com
On 19/07/2013 16:19, Thomas Monjalon wrote:
> The parameter PROJECT_NUMBER is used in the HTML header
> via the template variable $projectnumber.
>
> Signed-off-by: Thomas Monjalon
> ---
> mk/rte.sdkdoc.mk |2 ++
>
it is just look n feel, just push it.
Acked-by: vincent.jardin at 6wind.com
On 19/07/2013 16:19, Thomas Monjalon wrote:
> The version string is extracted from rte_version.h.
> RTE_VER_* macros are concatenated and separators " . . r " are inserted.
>
> Signed-off-by: Thomas Monjalon
> ---
> mk
Yes, it helps to avoid confusions, just push it.
Acked-by: vincent.jardin at 6wind.com
On 16/07/2013 10:35, Thomas Monjalon wrote:
> There is no network stack in DPDK API but only helpers for different layers.
>
> Signed-off-by: Thomas Monjalon
> ---
> doc/doxy-api-index.md |2 +-
> 1 fil
rrive.
> Simple tests like ping will fail.
>
> Signed-off-by: Stephen Hemminger
Reviewed-by: Vincent Jardin
It looks good. Thank you.
On 30/05/2013 19:12, Stephen Hemminger wrote:
> In many application there are no timers queued, and the call to
> rte_timer_managecan be optimized in that case avoid reading HPET and
> lock overhead.
>
> Signed-off-by: Stephen Hemminger
Reviewed-by: Vincent Jardin
It is a n
On 30/05/2013 19:12, Stephen Hemminger wrote:
> Both logging and calls to panic are never in the critical path.
> Use the GCC attribute cold to mark these functions as cold,
> which generates more optimised code.
>
> Signed-off-by: Stephen Hemminger
Reviewed-by: Vincent Jardin
I
> Signed-off-by: Stephen Hemminger
Reviewed-by: Vincent Jardin
All can be applied.
On 20/03/2013 17:04, Thomas Monjalon wrote:
> Here are some patches which were not integrated by Intel in their 1.2.3
> version.
>
> ---
>
> Adrien Mazarguil (3):
>lib: fix non-C99 macros definitions in exported headers
>pci: reference driver structure for each device
Welcome to the DPDK community. Please, use this mailing list to share
your patches, your questions and we'll provide you a best effort follow
up. Please, note that this mailing list cannot be used for a commercial
support. It is provided as-is.
Anyone can contribute, you are welcomed.
Best reg
> The rte_eth_dev_count() call returns 0, I am using a CentOS 6.3 Virtual
> Machine on VMWare esxi 5.0 on a Cisco UCS C220 M3 which comes with Xeon
> E5-2600.
Can you run lspci -vt and send us the output?
Best regards,
Vincent
Hi Antti,
We had to develop a complete logic from scratch (aka fast path logic) to
get a TCP/IP stack with good performances for 6WIND (including some
Openflow switching). Unfortunately, as part of our DPDK opensource
contribution, we do not plan to publish under open source our 6WINDGate
stac
gt; But IO scenario is very different from IP scenario as my understanding.
>
> March
>
> BTW: Do you have people at Bay Area?
>
>
> PS:
> Already finished header file for dpdk-iokit/libiokit_sctgt
>
>
>
>
>
>
I disagree Rashmin. We did measurements with 64 bytes packets: the Linux
kernel of the guest is the bottleneck, so the vmxnet3 PMD helps to
increase the packet rate of the Linux guests.
PMD helps within guest for packet rate until you rich (of course) the
bottleneck of the host's vSwitch.
In o
Hi Sujith,
NetBSD/Rump is the only open source TCP/IP stack for DPDK. Some people
may have tried to port LwIP too. As far as we know, only 6WIND has a
robust and fully compliant stack which provides socket APIs to the
applications on top of the DPDK. I'd be pleased to get a list of options
for
I do not know any open source implementation of an efficient LPM. FYI,
some data with a commercial one:
-> up to 160Mpps, the bottleneck was the IOs, not the CPU.
http://www.6wind.com/products/6windgate-protocols/ip-forwarding/
Best regards,
Vincent
On 24/09/2013 15:53, Jun Han wrote:
>
On 26/09/2013 23:16, Chris Pappas wrote:
> we are having some numbers regarding the performance of L3FWD and would
> like to confirm that they make sense.
> So, for L3FWD and 1500byte packets we get 120Gbps out of 12x10Gbps ports
> (so we get full throughput) and for 64byte packets we get 80Gbps.
FYI, there will be a seminar on Tuesday November the 5th in the San
Francisco bay area.
Register at:
http://www.6wind.com/seminars/dpdk/
It is for engineers who need a deep dive into the Intel(r) DPDK: the
seminar will cover its design, the details of available protocol stack
enhancemen
On 31/07/2014 22:32, John W. Linville wrote:
>> BTW: what is FESCO?
> Fedora Engineering Steering Committee
>
> Neil and I have already felt the hot breath of FESCO on our necks
> regarding the Fedora DPDK package...
>
I do confirm and feel that we should go step by step.
Having multiple library
On 01/08/2014 16:06, Neil Horman wrote:
> Thats a multi year effort, and not something I'm prepared to even
> consider undertaking.
Sorry: I am not pushing you, it was just an open comment. I do agree
that it is a multi year effort to get it down into a wide "agreed"
community. DPDK community ca
What's about using function versioning attributes too:
https://gcc.gnu.org/wiki/FunctionMultiVersioning
?
Le 7 ao?t 2014 22:11, "Neil Horman" a ?crit :
>
> On Thu, Aug 07, 2014 at 07:31:03PM +0100, Konstantin Ananyev wrote:
> > Make ACL library to build/work on 'default' architecture:
> > - mak
On 08/08/2014 09:41, Linhaifeng wrote:
> I have test the VFIO driver and IGB_UIO driver by l2fwd for many times. I
> find that the VFIO driver?s performance is not better than the IGB_UIO.
You are right, under some conditions UIO is faster, VFIO provides
safety. The best solution is a PMD without
> My cpu is "Intel(R) Xeon(R) CPU E5620 @ 2.40GHz"
It is a Westmere if I am correct. So,use UIO.
Good paper to read using DPDK:
http://fastpass.mit.edu/
> It's here:
> https://scan.coverity.com
>
> Some checks have been done with TrustInSoft Analyzer:
> http://dpdk.org/ml/archives/dev/2014-May/002365.html
> Noticeable example:
> http://dpdk.org/browse/dpdk/commit/?id=2612a4b935144accff
Registered on coverity, anyone for the admi
From today's call, I'd like to highlight that virtio-net-pmd (said code
B - from 6WIND) does not require UIO; it was required for some security
reasons of the guest Linux OS:
http://dpdk.org/browse/virtio-net-pmd/tree/virtio_user.c#n1494
Thank you,
Vincent
Le 17 d?c. 2014 04:15, "Stephen Hemminger" a
?crit :
>
> On Fri, 31 Oct 2014 15:53:19 -0700 (PDT)
> Thomas Monjalon wrote:
>
> > Hi,
> >
> > Talks related to DPDK can be proposed for FOSDEM 2015:
> > https://fosdem.org/2015/
> > This conference will take place in Belgium on 31 January & 1 F
>> +charifname[32]; /** Name of the tap device **/
>
> Linux and BSD the maximum network device name size is 16
>
In any case, please, use IF_NAMESIZE or IFNAMSIZ
see:
http://fxr.watson.org/fxr/ident?v=FREEBSD51;im=bigexcerpts;i=IF_NAMESIZE
You should use another virtio because it avoids uio constraints.
I have been using it to run testpmd on Virtualbox longtime ago.
See http://dpdk.org/browse/virtio-net-pmd/
Best regards,
Vincent
Le 8 f?vr. 2014 01:35, "Reda Haddad" a ?crit :
> Hi,
>
> I am getting a "write error: No such dev
> I guess the referenced virtio-net-PMD below is dpdk1.3 compatible but
> not necessarily a newer version. So I assume will need to update it for
> 1.6, etc.
Where do you see that it does not support the latest on dpdk.org?
http://dpdk.org/browse/virtio-net-pmd/log/virtio_user.c
About 1.6, sta
Hi Pravin,
Yes, it is a good integration with http://dpdk.org
Few feature questions:
- what's about the vNIC supports (toward the guests)?
- what's about IPsec support (VxLAN over IPsec for instance)?
I do not understand how your patch will solve those 2 cases.
>>> This is based a patch fr
Hi Pravin,
>> Few feature questions:
>>- what's about the vNIC supports (toward the guests)?
>>- what's about IPsec support (VxLAN over IPsec for instance)?
>> I do not understand how your patch will solve those 2 cases.
>>
> At this point I wanted to get basic DPDK support in OVS, once t
Hi Thomas,
On 29/01/2014 09:15, Thomas Graf wrote:
> The obvious and usual best practise would be for DPDK to guarantee
> ABI stability between minor releases.
>
> Since dpdk-dev is copied as well, any comments?
DPDK's ABIs are not Kernel's ABIs, they are not POSIX, there is no
standard. Cu
Thomas,
First and easy answer: it is open source, so anyone can recompile. So,
what's the issue?
> Without a concept of stable interfaces, it will be difficult to
> package and distribute RTE libraries, PMD, and DPDK applications. Right
> now, the obvious path would include packaging the PMD bit
On 02/06/2014 22:37, Chris Wright wrote:
> If drivers stayed in kernel and kernel drivers exposed a mechansim for
> registering application dma buffers for dpdk apps, then ethtool would
> simply work as-is.
Yes, that's the right way to go. Currently, the kernel does not provide
a generic framewor
On 19/05/2015 05:59, O'Driscoll, Tim wrote:
> a) Save the date. October 8th/9th, immediately after the European LinuxCon,
> in Dublin Ireland.
> b) Think about topics that you'd like to see covered. We'll solicit for
> inputs when the formal announcement is made, but it's good for people to
> be
On 19/05/2015 07:18, Butler, Siobhan A wrote:
>> Also related to this, I would hope to participate in any discussion about OVS
>> >acceration and vhost/guest access acceleration.
We need to have this track with both:
- Qemu/kvm/libvirt session during the LinuxCon,
- virtio session during the
Hi Scott,
Le 04/01/2017 à 22:09, Scott Daniels a écrit :
With holidays we are a bit late with our thoughts, but would like to
toss them into the mix.
Same, I hope I am not missing emails. I do appreciate your arguments, it
provides lot of light. See below,
The original NAK is understand
Nope. First one needs to assess if DPDK should be intensively used to
become a PF knowing Linux can do the jobs. Linux kernel community does not
like the forking of Kernel drivers, I tend to agree that we should not keep
duplicating options that can be solved with the Linux kernel.
Best regard
her.
Regards
KJ
On Jan 10, 2017, at 3:23 PM, Vincent Jardin wrote:
Nope. First one needs to assess if DPDK should be intensively used to
become a PF knowing Linux can do the jobs. Linux kernel community does not
like the forking of Kernel drivers, I tend to agree that we should not kee
Le 10/01/2017 à 22:32, Ferruh Yigit a écrit :
What do you think to continue high level DPDK PF discussion in mail
thread for other pathset? So that we can continue to work on this one.
First, we need to assess or not if it makes sense to go toward Linux
kernel or DPDK based PF. If Linux kernel
Thanks John for the kernel support. I'd like to add one thought on this
need from Joshi:
Also, the kernel drivers have no concept of passing VF messages to upstream
"decision making” (or policy enforcement) software like VFd.
It shall be possible to define some Netlink or policy management
Le 13/01/2017 à 07:52, Wenzhuo Lu a écrit :
+ * @b EXPERIMENTAL: this API may change without prior notice
a minor comment here:
+ including be removed.
shall remain with the experimental
status for any x message that is not supported by the kernel's PF.
The PF side of the DPDK implementation may be removed some days.
Series-Acked-By: Vincent Jardin
Le 16/01/2017 à 06:51, Wenzhuo Lu a écrit :
+ As an EXPERIMENTAL feature, please aware it can be changed or even
+ removed without prior notice.
thank you.
Le 16/01/2017 à 01:55, Zhang, Helin a écrit :
Acked-by: Helin Zhang
Acked-by: Vincent Jardin
Le 17/01/2017 à 21:14, Thomas Monjalon a écrit :
By the way, have you tried to work on glibc, as I had suggested?
Nothing here:
https://sourceware.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&ul=%2Fml%2Flibc-alpha%2F%25&q=memset
I do not see test to validate that the PF userland will look like a Linux
PF. I am getting concerned that it is a bad solution since we have
two/three PF mailboxes which may not be consistent: Linux, DPDK, VMware.
Le 16 décembre 2016 3:39:36 PM Ferruh Yigit a écrit :
1, VF Daemon (VFD)
VFD i
Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
+#ifdef RTE_LIBRTE_I40E_PMD
+ ret = rte_pmd_i40e_set_vf_unicast_promisc(res->port_id,
+ res->vf_id, is_on);
+#endif
Why is an ifdef used here? It won't scale to all PMDs.
I means that you are missing an abstraction layer
Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
+#ifdef RTE_LIBRTE_IXGBE_PMD
"set all queues drop (port_id) (on|off)\n"
"Set drop enable bit for all queues.\n\n"
"set vf split drop (port_id) (vf_id) (on|off)\n"
Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
+#ifdef RTE_LIBRTE_IXGBE_PMD
+ if (strstr(dev_info.driver_name, "ixgbe") != NULL)
+ ret = rte_pmd_ixgbe_set_vf_vlan_filter(res->port_id,
+ res->vlan_id, res->vf_mask, is_add);
+#endif
+#ifdef RTE_LIBRT
Le 16/12/2016 à 20:02, Ferruh Yigit a écrit :
As we need to support the scenario kernel PF + DPDK VF,
DPDK follows the interface between kernel PF + kernel VF.
Please, it has to be proven that DPDK provides the same interface that
the kernel. It seems insane to duplicate kernel's PF into the D
Le 19/12/2016 à 14:39, Chen, Jing D a écrit :
They will
have concern why VM can have such privilege (like promisc mode). But I need
to check as I know there is some mechanism now to make a VM privileged.
From iproute2's man:
<--
trust on|off - trust the specified VF user. This enables that VF u
Le 20/12/2016 à 05:48, Chen, Jing D a écrit :
That's a collaboration with another team. we'll follow-up that but not guarantee
it will happen.
May I ask if my reply make it clear? Still NAC for this patch?
Yes still nack, I am not confident with this PF approach since you are
breaking Linux PF
Le 19/12/2016 à 12:03, Ferruh Yigit a écrit :
And it is always possible to move these into ethdev layer, when multiple
PMDs supports same feature.
I agree this is something that needs to keep an eye on it, and be sure
if an API is generic, move it into eth_dev layer.
you are right, you have a g
Le 22/12/2016 à 09:10, Chen, Jing D a écrit :
In the meanwhile, we have some test models ongoing to validate combination of
Linux and
DPDK drivers for VF and PF. We'll fully support below 4 cases going forward.
1. DPDK PF + DPDK VF
2. DPDK PF + Linux VF
+ DPDK PF + FreeBSD VF
+ DPDK PF + Windo
Thanks for this update.
Still, I would like to get good arguments why DPDK should be a PF
because it creates fragmentations. Please, first, let's reply to:
http://dpdk.org/ml/archives/dev/2016-December/053107.html
Having both Linux and DPDK being PF, it means that we double the
combinations
Hi,
So, I understand from a call we had today that you'll send an update of
this series with:
- rte_membership for DPDK because it uses CRC+hash+rte_malloc+few EALs,
- calls to the lib bloom filter (to avoid forking code),
- using builtin/vectorized gcc instead of asm AVX code to keep it
Let's be back to 2014 with Qemu's thoughts on it,
+Stefan
https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026767.html
and
+Markus
https://lists.linuxfoundation.org/pipermail/virtualization/2014-June/026713.html
6. Device models belong into QEMU
Say you build an actual
Le 17/03/2017 à 01:11, Wiles, Keith a écrit :
it seems like some other hidden agenda is at play here, but I am a paranoid
person :-)
Keith, please stop such invalid argument! It is non sense.
We need to understand the benefits of diverging from virtio since here
it is about creating new devi
Le 17 mars 2017 11:15:22 AM Thomas Monjalon a
écrit :
2017-03-17 09:45, Zhang, Helin:
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
>2017-03-17 03:28, Zhang, Helin:
>> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
>> > 2017-02-23 13:27, Qi Zhang:
>> > > static void
>
Le 18 mars 2017 00:03:08 Thomas Monjalon a écrit :
2017-03-17 21:14, Vincent Jardin:
Please, can you bring it to the next tech board? This dispersion of VF/PF
make the DPDK unusable into open products with many parties since behavior
becomes VF/PF specific.
Already requested earlier in
Le 23 mars 2017 7:28:02 PM "Legacy, Allain" a
écrit :
-Original Message-
From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
Sent: Thursday, March 23, 2017 10:18 AM
<...>
Hi Allain,
Overall PMD looks good to me.
Only can you please update documentation based on tech board decisio
Le 28/03/2017 à 13:53, Allain Legacy a écrit :
This patch series submits an initial version of the AVP PMD from Wind River
Systems. The series includes shared header files, driver implementation,
and changes to documentation files in support of this new driver. The AVP
driver is a shared memory
Le 4 avril 2017 4:28:47 AM Stephen Hemminger a
écrit :
On Mon, 3 Apr 2017 22:53:06 +
"Wiles, Keith" wrote:
> On Apr 3, 2017, at 2:51 PM, Stephen Hemminger
wrote:
>
> On Thu, 30 Mar 2017 18:09:04 +
> "Dumitrescu, Cristian" wrote:
>
>>> -Original Message-
>>> From: dev [
Le 16/02/2017 à 12:06, Thomas Monjalon a écrit :
The request (6 month ago) was to give more time for feedbacks:
http://dpdk.org/ml/archives/dev/2016-July/044847.html
Is it time now to officially remove Dom0 support?
yes
Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit :
Is it time now to officially remove Dom0 support?
So we do have an prototype implementation of netback but it is waiting
for review of xen-devel to the spec.
And I believe the implementation does utilize some of the dom0
parts of code in DP
Le 17/02/2017 à 13:13, Bruce Richardson a écrit :
If it builds without an SDK dependency I'd be happy enough to see this
merged into DPDK.
+1, the patch is clean enough to be compiled.
Boards or CPUs can rely on specific SDK, firmware, etc., it is up to the
vendors.
regards,
Vincent
Le 24/02/2017 à 08:23, Lu, Wenzhuo a écrit :
It is good to allow setting QoS on device, but it looks like this is a device
specific API, not a generic PMD function. I don't think any feature in DPDK
should be hardcoded to one device type.
Yes, they're private APIs.
Normally we want to support ke
Le 26/02/2017 à 20:08, Allain Legacy a écrit :
This patch series submits an initial version of the AVP PMD from Wind River
Systems. The series includes shared header files, driver implementation,
and changes to documentation files in support of this new driver. The AVP
driver is a shared memory
Le 02/03/2017 à 01:20, Allain Legacy a écrit :
+Since the initial implementation of AVP devices, vhost-user has become
+part of the qemu offering with a significant performance increase over
+the original virtio implementation. However, vhost-user still does
+not achieve the level of performance
Allain,
see inline,
+ I did restore the thread from
http://dpdk.org/ml/archives/dev/2017-March/060087.html into the same email.
To make it short, using ivshmem, you keep people unfocused from virtio.
Vincent,
Perhaps you can help me understand why the performance or functionality of
AVP vs.
Le 15/03/2017 à 05:10, O'Driscoll, Tim a écrit :
so, still an nack because:
- no performance data of avp vs virtio,
I don't think it should be a requirement for Allain to provide performance data
in order to justify getting this accepted into DPDK. Keith pointed out in a
previous comment on
Le 15/03/2017 à 05:10, O'Driscoll, Tim a écrit :
so, still an nack because:
- no performance data of avp vs virtio,
I don't think it should be a requirement for Allain to provide performance data
in order to justify getting this accepted into DPDK. Keith pointed out in a
previous comment on
Le 15/03/2017 à 12:29, Ferruh Yigit a écrit :
The scope of the patch is limited to PMD.
As long as it is maintained, it is good to have alternative approaches.
From your logic, then, how many PMDs can be accepted?
See my previous email: techboard should not bypass discussion of the
dev@ maili
Le 15/03/2017 à 11:55, Thomas Monjalon a écrit :
I'd suggest that this is a good topic for the next Tech Board meeting.
I agree Tim.
CC'ing techboard to add this item to the agenda of the next meeting.
Frankly, I disagree, it is missing some discussions on the list.
Le 26 octobre 2016 2:11:26 PM "Van Haaren, Harry"
a ?crit :
>> -Original Message-
>> From: dev [mailto:dev-bounces at 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 i
Le 28 octobre 2016 9:23:06 PM Igor Ryzhov a ?crit :
> On Fri, Oct 28, 2016 at 9:40 PM, Thomas Monjalon 6wind.com>
> wrote:
>
>> 2016-10-28 20:29, Igor Ryzhov:
>> > On Fri, Oct 28, 2016 Thomas Monjalon wrote:
>> > > 2016-10-28 15:51, Richardson, Bruce:
>> > > > From: dev [mailto:dev-bounces at
Why duplicating Jyri's libbloom - https://github.com/jvirkki/libbloom - for
this DPDK capability? Why not showing that you can contribute to libbloom
and make it linkable with the DPDK?
There are so many duplicated code...
Thank you,
Vincent
dentified.
So let's start first with contributions to libbloom, please.
Thanks
Yipeng
-Original Message-
From: Vincent Jardin [mailto:vincent.jar...@6wind.com]
Sent: Saturday, May 27, 2017 2:42 AM
To: Wang, Yipeng1
Cc: dev@dpdk.org; Gobriel, Sameh ; Wang, Ren
; Tai, Charlie
Su
Thomas, Changchun,
On 29/07/2015 14:56, Thomas Monjalon wrote:
> Back on this old patch, it seems justified but nobody agreed.
>
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -1288,7 +1288,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
>
> Use '--disable-hw-vlan-filter' in testpmd command line will allow it
> continue to work.
> You can have a try.
Yes, but not using this flag should not imply to exit.
> I am not sure which one is better when app configures one feature but fail to
> negotiate it with host(which means has
> no
On 12/08/2015 10:02, Ouyang Changchun wrote:
> +#define VMDQ_RSS_RX_QUEUE_NUM_MAX 4
> +
> +static int
> +rte_eth_dev_check_vmdq_rss_rxq_num(__rte_unused uint8_t port_id, uint16_t
> nb_rx_q)
> +{
> + if (nb_rx_q > VMDQ_RSS_RX_QUEUE_NUM_MAX)
> + return -EINVAL;
> + return 0;
> +}
On 01/12/2015 15:27, Panu Matilainen wrote:
> The problem with that (unless I'm missing something here) is that KNI
> requires using out-of-tree kernel modules which makes it pretty much a
> non-option for distros.
It works fine with some distros. I do not think it should be an argument.
Thanks Thomas for putting back this topic.
Alex,
I'd like to hear more about the impacts of "unsupported":
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=033291eccbdb1b70ffc02641edae19ac825dc75d
Use of this mode, specifically binding a device without a native
IOM
On 15/12/2015 22:15, Wiles, Keith wrote:
> I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of
> when a release was done.
+1
I like it.
On 17/12/2015 20:38, Jan Viktorin wrote:
> which platforms (or computer systems) I am targeting?
It is about VMs on IOMMU capable systems. What if you need to use SRIOV
with IXGBE, or IGB devices?
For some DPDK cases, like Mellanox or virtio, you do not need to use
VFIO/UIO into the guests, so
Le 23 d?c. 2015 10:12, "Qiu, Michael" a ?crit :
>
> Is it suitable to put so many code in commit log?
It is more explicit than a text/comment. I do not think it should be
maintained code.
>
> Thanks,
> Michael
> On 12/22/2015 5:36 PM, Didier Pallard wrote:
> > As demonstrated by the following co
Le 23/05/2018 à 07:52, Wang, Qihua (NSB - CN/Hangzhou) a écrit :
Hi DPDK expert,
I am Nokia engineer. We are upgrading 6wind from 6wind 4.13->4.17, with DPDK
upgrading from 16.04->17.05. We use AVP PMD driver.
From the performance test result, the CPU load of RX core increase from 72% to
94% u
Thanks Jim...
When I started in 2010 with Venky, when we were reinventing the world of
software networking it was a pleasure to brainstorm with him, to get his
prototypes and then use them as foundations to build new librairies for
packet processing.
In fact Venky was someone who wanted to wor
Le 10/01/2018 à 10:27, Richardson, Bruce a écrit :
Hi Bruce,
Just curious, can you provide some hints on percent increase in at least
some representative cases? I'm just trying to get a sense of if this is
%5, 10%, 20%, more... I know mileage will vary depending on system, setup,
configuration,
+1 with Thomas, see below,
Le 12/10/2017 à 08:51, Tomasz Duszynski a écrit :
What is MUSDK_DMA_MEMSIZE?
If the value cannot change, it must be a constant in the code.
If it can change, it should be a run-time driver option.
It's up to the user what MUSDK_DMA_MEMSIZE is going to be. Currently it
Le 12/10/2017 à 14:14, Jacek Siuda a écrit :
What we can do, is to add a run-time driver option and oblige user (in
documentation) to set the option only for the first mrvl vdev. If the
driver doesn't see the option set, it won't initialize DMA. This, plus
meaningful error handling/logs shou
1 - 100 of 133 matches
Mail list logo
