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
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
Le 30/03/2016 23:50, Stephen Hemminger a ?crit :
> Do we want to require DPDK to work in the face of every weird vendor
> kernel backport. This is a road to nowhere...
+1 with Steve. No way! There is no rational.
Le 10 mars 2016 01:06, "Thomas Monjalon" a
?crit :
>
> 2016-03-02 23:35, Thomas Monjalon:
> > 2016-03-02 12:21, Thomas Monjalon:
> > > 2016-03-02 11:47, Vincent JARDIN:
> > > > Le 02/03/2016 09:27, Panu Matilainen a ?crit :
> > > > >>&
Please,
Le 02/03/2016 22:30, Stephen Hurd a ?crit :
> Too many of the DPDK drivers are bloated.
>>Recall the venerable paraphrase of Pascal, "I made this so long because I
>>did not have time to make it shorter."
>>https://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read
Keep In Simple,
Le 02/03/2016 11:51, Jim Thompson a ?crit :
> Can we take it as a requirement to support FreeBSD this time around?
Of course, all OS should be on the loop, but I guess, it would be per
kernel specific. What is ethtool on FreeBSD? Or can you start porting
ethtool on FreeBSD?
Le 02/03/2016 09:27, Panu Matilainen a ?crit :
>>> I'd like to see these be merged.
>>>
>>> Jay
>>
>> The code is really not ready. I am okay with cooperative development
>> but the current code needs to go into a staging type tree.
>> No compatibility, no ABI guarantees, more of an RFC.
>> Don't
Thomas,
> I am not sure if anyone has noticed yet this but is the dpdk snapshot
> bad today?
can you check again?
For 2 download:
$ md5sum dpdk-2.2.0*gz
22e2fd68cd5504f43fe9a5a6fd6dd938 dpdk-2.2.0 (1).tar.gz
22e2fd68cd5504f43fe9a5a6fd6dd938 dpdk-2.2.0.tar.gz
tar tvzf is ok too.
Thanks for
A new project using DPDK is available,
http://FD.io
said
FiDo
You can clone it from:
http://gerrit.fd.io/
Best regards,
Vincent
On 11/02/2016 02:12, Stephen Hemminger wrote:
> I would rather the macros were aligned with ixgbe which always
> adds newline for all the PMD_XXX_LOG() macros. And then remove
> all extra newlines in virtio code.
you right
PMD_TX_LOG() looks better with a \n
Signed-off-by: Vincent JARDIN
---
drivers/net/virtio/virtio_rxtx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 41a1366..c03d36a 100644
--- a/drivers
When CONFIG_RTE_LIBEAL_USE_HPET=y is set, eal_timer.c does not compile
anymore. Just add simple missing include.
Signed-off-by: Vincent JARDIN
---
lib/librte_eal/linuxapp/eal/eal_timer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_timer.c
b/lib
On 21/01/2016 08:29, David Marchand wrote:
> Hello,
>
> On Thu, Jan 21, 2016 at 8:24 AM, Zhe Tao wrote:
>> Add the new floating related argument option in the EAL.
>> using this parameter, all the samples can decide whether to use legacy
>> VEB/VEPA,
>> or floating VEB.
>
> Not familiar with
Le 14 janv. 2016 22:39, "Wang, Zhihong" a ?crit :
>
>
>
> > -Original Message-
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Friday, January 15, 2016 12:49 AM
> > To: Wang, Zhihong
> > Cc: dev at dpdk.org; Ananyev, Konstantin ;
> > Richardson, Bruce ; Xie,
> [Wenzhuo] The udp_tunnel_add and udp_tunnel_del have already existed. I
just use them. Honestly I agree with you they are not accurate name. Better
change them to udp_tunnel_port_add and udp_tunnel_port_del. But it should
be a ABI change if I?m not wrong. I think we can announce it this release
see inline
Le 11 janv. 2016 08:08, "Wenzhuo Lu" a ?crit :
>
> Add UDP tunnel add/del support on ixgbe. Now it only support
> VxLAN port configuration.
> Although the VxLAN port has a default value 4789, it can be
> changed. We support VxLAN port configuration to meet the
> change.
> Note, the
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
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
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.
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
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.
On 05/11/2015 11:43, Alejandro.Lucero wrote:
> From: "Alejandro.Lucero"
>
> This patchset adds a new PMD for Netronome nfp-6xxx card.
> Just PCI Virtual Functions supported.
> Using this PMD requires previous Netronome BSP installation.
>
I understand that this PMD needs a kernel driver which
Le 3 nov. 2015 23:05, "Bagh Fares" a ?crit :
>
> Tim
> Good clafication. What is the governance model. Can you point me to it?
Thanks
First sentence of
http://dpdk.org/dev
is
" Anyone is welcome to contribute."
Best regards,
>
> -Original Message-
> From: O'Driscoll, Tim
On 20/10/2015 09:53, Qiu, Michael wrote:
> But as I know it is different all the time, am I right?
> If yes, I don't know what's the value of this field.
It can be used to get some snapshot/instant view informations while we
have to monitor and debug.
Thomas, John,
thanks for your notes.
Enclosed the contents of our chats,
On 13/10/2015 18:36, Mcnamara, John wrote:
> * PMD lite
>
>- Do we need a lighter PMD model? Perhaps based on the Mellanox
> model.
>- Vincent suggested be could remove 90% of the code. I'll leave
>
On 13/10/2015 18:36, Mcnamara, John wrote:
> * Should DPDK applications be running as root
>
>- Clearly not a great option.
>
>- Currently required due to kernel.
It is not 100% accurate. With some systems, it shall be possible to run
DPDK application without running them as root.
It
On 13/10/2015 22:06, Thomas Monjalon wrote:
> 2015-10-13 16:36, Mcnamara, John:
>> > - Move the EAL to the kernel.
> Please explain what you mean here.
> It's difficult to imagine.
>
+Martin at ARM on it. We were rising this topic with him last week.
Le 6 oct. 2015 09:54, "Stephen Hemminger" a
?crit :
>
> On Mon, 5 Oct 2015 19:54:35 +0200
> Adrien Mazarguil wrote:
>
> > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4
> > (mlx5) adapters can take advantage of, such as:
> >
> > - Separate post and doorbell operations
On 01/10/2015 11:43, Avi Kivity wrote:
>
> That is because the device itself contains an iommu.
Yes.
It could be an option:
- we could flag the Linux system unsafe when the device does not have
any IOMMU
- we flag the Linux system safe when the device has an IOMMU
On 01/10/2015 11:22, Avi Kivity wrote:
>> As far as I could see, without this kind of motivation, people do not
>> even want to try.
>
> You are mistaken. The problem is a lot harder than you think.
>
> People didn't go and write userspace drivers because they were lazy.
> They wrote them because
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;
>
> 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
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)
>
On 18/06/2015 18:55, O'Driscoll, Tim wrote:
> I like Olivier's proposal on using a single option (CONFIG_RTE_NEXT_ABI) to
> control all of these changes instead of a separate option per patch set
> (seehttp://dpdk.org/ml/archives/dev/2015-June/019147.html), so I think we
> should rework the
On 17/06/2015 14:14, Panu Matilainen wrote:
> (initially accidentally sent to announce, resending to dev)
>
> On 06/17/2015 01:35 PM, Neil Horman wrote:
>> On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
>>> Hi all,
>>>
>>> Sometimes there are some important discussions about
pt patch set.
> They're 1) struct rte_intr_handle; 2) struct rte_intr_conf.
>
> Signed-off-by: Cunming Liang
Acked-by: vincent jardin
On 27/05/2015 22:48, Thomas F Herbert wrote:
> Work Flow and Process:
>
> All patches will be taken from from public submissions to dpdk-dev.org
> scraped from dpdk patchwork. Patches will be applied to the patch-test
> tree and tested against HEAD as they are received. The feedback from the
>
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
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
>
On 11/02/2015 05:50, Ouyang, Changchun wrote:
> As we know proc/ioports hasn't interrupt, 6wind implementation also don't
> introduce interrupt in it.
correct, it is running without interrupt, they are not mandatory.
>> +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
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
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
Tim,
cc-ing Paolo and qemu-devel@ again in order to get their take on it.
>>> Did you make any progress in Qemu/KVM community?
>>> We need to be sync'ed up with them to be sure we share the same goal.
>>> I want also to avoid using a solution which doesn't fit with their plan.
>>> Remember that
+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
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
+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
FYI, on Monday, there will be a presentation of DPDK applications
running with Openstack:
http://sched.co/XnatsK
Best regards,
Vincent
Good paper to read using DPDK:
http://fastpass.mit.edu/
> My cpu is "Intel(R) Xeon(R) CPU E5620 @ 2.40GHz"
It is a Westmere if I am correct. So,use UIO.
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
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
> +#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
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
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
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:
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
> 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,
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
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
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.
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
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
> 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
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
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.
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:
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
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
> ---
>
> 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
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
72 matches
Mail list logo
