When use i40e linux kernel driver as host driver and DPDK handler the i40e
VF, the promiscuous mode doesn't work in i40e VF. It is not supported by
DPDK i40e VF driver right now.
Signed-off-by: Jeff Guo
---
v2->v3:
- Title underline align and refine some description
doc/guides/rel_notes/known_i
Hi Konstantin,
On 7/19/2016 6:29 PM, Ananyev, Konstantin wrote:
>
>> Problem:
>> When using the TSO + VXLAN feature in i40e, the outer UDP length fields in
>> the multiple UDP segments which are TSOed by the i40e will
>> have a wrong value.
>>
>> Fix this problem by adding the tunnel type field
Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions
Fixes: 2de9f8551ff9 ("ethdev: fix documentation for queue start/stop")
Signed-off-by: Nikhil Rao
---
v2:
* Updated as per review comments from John McNamara.
* Previous patch did not apply on master.
* Used started/stopped fo
Signed-off-by: Olga Shern
---
doc/guides/nics/mlx5.rst |7 ++-
doc/guides/rel_notes/release_16_07.rst | 16 +++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 063c4a5..1bcb818 100644
--
Signed-off-by: Shreyansh Jain
---
doc/guides/testpmd_app_ug/build_app.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/testpmd_app_ug/build_app.rst
b/doc/guides/testpmd_app_ug/build_app.rst
index 7f32a7c..4c7cf2e 100644
--- a/doc/guides/testpmd_app_ug/build_app.
The right name of ethdev should be dpdk_netdev. However:
1/ We are using rte_ prefix in the code and library names.
2/ The API uses rte_ethdev
That's why 16.11 will just have the rte_ prefix prepended to
the library filename as every other libraries.
Signed-off-by: Thomas Monjalon
---
doc/guides
From: nikhil@intel.com
Fix documentation for rte_eth_dev_tx/rx_queue_start/stop() functions
Signed-off-by: Nikhil Rao
---
lib/librte_ether/rte_ethdev.h | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethde
This patch documents the new l2fwd option, which provides a way to
disable the MAC addresses tweaking, enabling the use of l2fwd for basic
VM to VM communication.
Signed-off-by: Maxime Coquelin
---
doc/guides/sample_app_ug/img/l2_fwd_vm2vm.svg | 311 +
.../sample_app_ug/
l2fwd could be useful for testing virtual devices without the need
of physical ones.
To achieve this, this patch adds a new option to enable/disable the
MAC addresses tweaking done at forwarding time: --[no-]mac-tweaking
By default, MAC address tweaking remains enabled, to keep consistency
with p
This series adds a new option to enable/disable MAC addresses tweaking in
l2fwd example.
Doing that, we can enable basic VM 2 VM communication easily, without
external projects dependencies, nor real NIC (as with vhost example).
Example of cli with vhost-user:
#l2fwd -c f --socket-mem=1024 \
The '-' in lcore set overrides cpu set of following
lcore set in the argument of EAL option --lcores.
for example --locres '0-2,(3-5)@(3,4),6@(5,6),7@(5-7)',
0-2 make lflags=1 which indeed suppress following
cpu set (3,4), (5,6) and (5-7) after @ .
Fixes: 53e54bf81700 ("eal: new option --lcores fo
local variable i is not referred by other codes in
the function eal_parse_lcores( ), so it can be removed.
Signed-off-by: Wei Dai
---
lib/librte_eal/common/eal_common_options.c | 4
1 file changed, 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/com
On Tue, Jul 26, 2016 at 11:51:57AM +, Ananyev, Konstantin wrote:
>
>
hi Wei,
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Dai
> > Sent: Tuesday, July 26, 2016 10:52 AM
> > To: dev at dpdk.org
> > Cc: Dai, Wei
> > Subject: [dpdk-dev] [PATCH v2
Hi,
I am trying to enable virtio for our application. The driver
registration is all working and initialization is fine as well. But, when
I call "*rte_eth_rx_burst()*" API to receive packets, driver crashes "
*virtio_recv_mergeable_pkts()*" while calling "VIRTQUEUE_NUSED()". Looks
like th
Hi,
I forgot to add the i40 maintainers as well. Would anyone like to weigh in?
Regards,
Zoltan
On 22/07/16 12:34, Zoltan Kiss wrote:
>
>
> On 21/07/16 19:58, bynes adam wrote:
>> On Wed, Jul 20, 2016 at 06:11:16PM +0100, Zoltan Kiss wrote:
>> Hi, Kiss
>>> Using weak symbols have a few issues w
2016-07-26 14:23, Ferruh Yigit:
> On 7/21/2016 5:41 PM, Thomas Monjalon wrote:
> > About the point 1, if we decide to keep KNI ethtool, please could you
> > duplicate the igb/ixgbe PCI ids in KNI?
>
> Sure, I am not aware of exactly what needs to be done, please show me.
We just need to remove th
On Monday, July 07/25/16, 2016 at 09:40:02 -0700, John Fastabend wrote:
> On 16-07-25 04:32 AM, Rahul Lakkireddy wrote:
> > Hi Adrien,
> >
> > On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil wrote:
> >> Hi Rahul,
> >>
> >> Please see below.
> >>
> >> On Thu, Jul 21, 2016 at 01
Hello,
While working on uploading DPDK to Ubuntu and Debian, we were wondering
if anyone had any thoughts/opinions on enabling compiler hardening flags
for the DPDK libraries and the possible performance implications.
Especially 2 of the hardening options provided on Debian/Ubuntu [1]
explicitly
> -Original Message-
> From: Rao, Nikhil
> Sent: Tuesday, July 26, 2016 3:13 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Yigit, Ferruh ;
> Mcnamara, John ; Rao, Nikhil
>
> Subject: [PATCH v2] ethdev: fix documentation for queue start/stop
>
> Fix documentation for rte_eth
On 7/21/2016 5:41 PM, Thomas Monjalon wrote:
> 2016-07-21 16:41, Igor Ryzhov:
>> On Thu, Jul 21, 2016 at 4:33 PM, Ferruh Yigit
>> wrote:
>>> On 7/20/2016 5:07 PM, Thomas Monjalon wrote:
The out-of-tree kernel code must be avoided.
Moreover there is no good reason to keep this legacy feat
> -Original Message-
> From: Guo, Jia
> Sent: Tuesday, July 26, 2016 3:24 AM
> To: Mcnamara, John
> Cc: dev at dpdk.org; Guo, Jia
> Subject: [PATCH v2] doc: add known issue about promiscuous mode for I40e
> VF
>
> When use i40e linux kernel driver as host driver and DPDK handler the i40e
On 7/22/2016 6:20 PM, Andriy Berestovskyy wrote:
> Hi folks,
> Just to clarify. Thomas is talking about removing just the KNI ethtool
> (i.e. lib/librte_eal/linuxapp/kni/ethtool/*). The major functionality
> of those 45K lines of code is to get the same MAC address on the KNI
> interface and the un
> -Original Message-
> From: Pei, Yulong
> Sent: Tuesday, July 26, 2016 4:33 AM
> To: dev at dpdk.org; thomas.monjalon at 6wind.com
> Cc: Mcnamara, John ; Pei, Yulong
>
> Subject: [PATCH v3] doc: add section on tested platforms and nics and OSes
>
> Add new section on tested platforms and
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mcnamara, John
> Sent: Tuesday, July 26, 2016 2:57 PM
> To: Shreyansh Jain ; De Lara Guarch, Pablo
>
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app
>
> >
> >
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shreyansh Jain
> Sent: Tuesday, July 26, 2016 2:32 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: fix incorrect path to testpmd app
>
> Signed-off-by: Shreyansh Jain
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nikhil P Rao
> Sent: Tuesday, July 26, 2016 1:37 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Rao, Nikhil
> Subject: [dpdk-dev] [PATCH] ethdev: fix documentation for queue start/stop
> functions
From: Dumitru Ceara
The driver is incorrectly setting the RSS field in the last mbuf in
the packet chain instead of the first. Moreover, the last mbuf might
have already been freed if it only contained the Ethernet CRC.
Also, fix the call to i40e_rxd_build_fdir to store the fdir flags in
the fir
> -Original Message-
> From: dumitru.ceara at gmail.com [mailto:dumitru.ceara at gmail.com]
> Sent: Tuesday, July 26, 2016 11:46 AM
> To: dev at dpdk.org
> Cc: Xing, Beilei ; Zhang, Helin intel.com>; Wu, Jingjing ; Ananyev, Konstantin
> ; Dumitru Ceara
> Subject: [PATCH] net/i40e: fix s
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Dai
> Sent: Tuesday, July 26, 2016 10:52 AM
> To: dev at dpdk.org
> Cc: Dai, Wei
> Subject: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse
> --lcores
>
> local variable i is not referred
Add new section on tested platforms and nics and OSes to the release notes.
Signed-off-by: Yulong Pei
---
doc/guides/rel_notes/release_16_07.rst | 119 ++---
1 file changed, 111 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_07.rst
b/doc/
Hi Beilei,
On Tue, Jul 26, 2016 at 10:47 AM, Zhang, Helin wrote:
> Hi Ceara
>
> For testpmd command line, txqflags = 0xf01 should be set for receiving
> packets which needs more than one mbufs.
> I am not sure if it is helpful for you here. Please have a try!
>
Just tried, and it doesn't really
Hi Beilei,
On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara wrote:
> Hi Beilei,
>
> On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei
> wrote:
>> Hi,
>>
>>> -Original Message-
>>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
>>> Sent: Friday, July 22, 2016 8:32 PM
>>> To: Xing, Beilei
Hi,
There was lengthy discussions w.r.t external mempool patches.
However, I am still finding usages issue with the agreed approach.
The existing API to create packet mempool, "rte_pktmbuf_pool_create" does not
provide the option to change the object init iterator. This may be the
rx_good_bytes and rx_good_packets statstic is inconsistent when port
stopped,ipackets statistic is minus the discard packets but rx_bytes statistic
not.
Also,i40e has no statstic of discard bytes, so we have to delete discard
packets item from rx_good_packets statstic.
Fixes: 9aace75fc82e ("i40
On Tue, Jul 26, 2016 at 02:53:13PM +, Luca Boccassi wrote:
> While working on uploading DPDK to Ubuntu and Debian, we were wondering
> if anyone had any thoughts/opinions on enabling compiler hardening flags
> for the DPDK libraries and the possible performance implications.
Most of the C prof
Hi Dumitru,
>
> Hi Beilei,
>
> On Mon, Jul 25, 2016 at 12:04 PM, Take Ceara
> wrote:
> > Hi Beilei,
> >
> > On Mon, Jul 25, 2016 at 5:24 AM, Xing, Beilei
> > wrote:
> >> Hi,
> >>
> >>> -Original Message-
> >>> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> >>> Sent: Friday
Hi Ceara
For testpmd command line, txqflags = 0xf01 should be set for receiving packets
which needs more than one mbufs.
I am not sure if it is helpful for you here. Please have a try!
Regards,
Helin
> -Original Message-
> From: Take Ceara [mailto:dumitru.ceara at gmail.com]
> Sent: Tue
> > > The problem is that -lrt appears before -lrte_eal.
> > > The question is: where does it come from?
> > > It is even before _LDLIBS-y += -L$(RTE_SDK_BIN)/lib... mystery
> >
> > root cause:
> > commit c7cda4d8b4ea9cb0f209dda36882d225354b1db9
>
> The error is seen after this commit, yes.
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Guo
> Sent: Tuesday, July 26, 2016 10:24 AM
> To: Mcnamara, John
> Cc: dev at dpdk.org; Guo, Jia
> Subject: [dpdk-dev] [PATCH v2] doc: add known issue about promiscuous
> mode for I40e VF
>
> When use i40
Tested-by: Peng Yuan
- Test Commit: 6baf0eca5cfa068621ee15605159523918109661
- OS/Kernel: 4.5.7-202.fc23.x86_64
- GCC: gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)
1. Bind 1 pf to igb_uio
2. use the pf to generate 2 VFs
3. rmmod i40evf
4. launch testpmd with PF with or without floating veb
Fixes: 9b15ba895b9f ("timer: use a skip list")
2016-07-23 7:05 GMT+09:00 Sanford, Robert :
>
>
> On 7/17/16 10:35 AM, "Hiroyuki Mikita" wrote:
>
>>This commit fixes incorrect pending-list manipulation
>>when getting list of expired timers in rte_timer_manage().
>>
>>When timer_get_prev_entries()
Fixes: a4b7a5a45cf5 ("timer: fix race condition")
2016-07-23 7:06 GMT+09:00 Sanford, Robert :
>
>
> On 7/17/16 1:35 PM, "Hiroyuki Mikita" wrote:
>
>>When timer_set_running_state() fails in rte_timer_manage(),
>>the failed timer is put back on pending-list.
>>In this case, another core tries to re
Fixes: a4b7a5a45cf5 ("timer: fix race condition")
2016-07-25 23:43 GMT+09:00 Thomas Monjalon :
> Hiroyuki, Robert,
> I would like to apply these patches quickly.
> Please could you provide some "Fixes:" line to know the origin
> of the bugs?
> Thanks
>
43 matches
Mail list logo