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 07/03/2018 à 04:56, sujith sankar a écrit :
Is PMD for Broadcom/Emulex OCe14000 OCP Skyhawk-R available? There
are a few documents in Broadcom's site. But could not find the source
code of it.
Right, it has not been upstreamed. Currently, it is even deprecated at
6WIND for our new release
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,
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 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
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
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
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
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 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 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 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 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 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
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 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 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 à 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
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 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
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 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 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 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 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 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
Le 16/01/2017 à 01:55, Zhang, Helin a écrit :
Acked-by: Helin Zhang
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.
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 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.
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 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
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
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
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
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
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
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 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 à 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 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 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 :
+#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_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
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
Tim,
Thanks for your draft, but it is not a good proposal. It is not written
in the spirit that we have discussed in Dublin:
- you create the status of "Gold" members that we do not want from
Linux Foundation,
- you start with "DPDK?s first $1,000,000", it is far from the $O
that we agree
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 i
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, Sm
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 w
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 t
Le 16/02/2016 17:22, O'Driscoll, Tim a ?crit :
>
>> -Original Message-
>> From: announce [mailto:announce-bounces at dpdk.org] On Behalf Of Thomas
>> Monjalon
>> Sent: Monday, February 15, 2016 3:15 PM
>> To: announce at dpdk.org
>> Subject: [dpdk-announce] call to join Linux Foundation
>>
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 th
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, H
> [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
a
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 def
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
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
IOM
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 is
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 [mailto:tim.o
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
> Vincen
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 was
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
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 affe
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 archi
terrupt 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
> test
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
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 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 F
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 w
+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 F
+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
FYI, on Monday, there will be a presentation of DPDK applications
running with Openstack:
http://sched.co/XnatsK
Best regards,
Vincent
> 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
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.
1 - 100 of 133 matches
Mail list logo
