Hi Jay,
I won't try to interpret your kernel stack trace. But, I'll tell you about
a KNI-related problem that we once experienced, and the symptom was a
kernel hang.
The problem was that we were passing mbufs allocated out of one mempool,
to a KNI context that we had set up with a different mempo
> > The cryptodev API was introduced in the DPDK 2.2 release.
> > Since then it has
> > - been reviewed and iterated for the DPDK 16.04 release
> > - had extensive use by the l2fwd-crypto app,
> > the ipsec-secgw example app,
> > the test app.
> > We believ
2016-04-04 18:14, Fiona Trahe:
> renamed rte_cryptodev_sym_session.type -> dev_type
> (as it's not a session type, but a device type)
>
> renamed rte_crypto_sym_op.type -> sess_type
> (as it's not an op type, but a session type)
>
> Signed-off-by: Fiona Trahe
Applied, thanks
> > A new process to request the libsso library required by the SNOW3G PMD
> > has been put in place, through a website, replacing the previous email
> > method.
> > This commit updates the SNOW3G documentation, to reflect this change.
> >
> > Since the library does not support newer gcc versions,
2016-04-04 14:14, Pablo de Lara:
> This patchset fixes some minor typos in the Crypto PMD documentation
> and add an extra section to help user to initialize the devices.
>
> The patchset depends on:
> "doc: update the snow3g library information"
> (http://dpdk.org/dev/patchwork/patch/11889/)
>
2016-04-06 18:29, Thomas Monjalon:
> 2016-04-06 16:39, Pablo de Lara:
> > AES-GCM PMD only supports 128-bit keys, but not 192 and 256,
> > which the capabilities structure was reporting.
> >
> > Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
>
> I think you mean
> Fixes: 26c
2016-04-06 16:46, Trahe, Fiona:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > v2:
> >
> > The v2 is missing in the title (option -v2 in git).
> Sorry :(
> Do you want me to resend with updated subject?
No, it was just for information for next times.
2016-04-06 13:03, Yuanhan Liu:
> On Tue, Apr 05, 2016 at 05:09:47PM +0100, Ciara Loftus wrote:
> > After some testing, it was found that retrieving numa information
> > about a vhost device via a call to get_mempolicy is more
> > accurate when performed during the new_device callback versus
> > the
2016-04-06 12:05, Fiona Trahe:
> The cryptodev API was introduced in the DPDK 2.2 release.
> Since then it has
> - been reviewed and iterated for the DPDK 16.04 release
> - had extensive use by the l2fwd-crypto app,
> the ipsec-secgw example app,
> the
2016-04-06 16:39, Pablo de Lara:
> AES-GCM PMD only supports 128-bit keys, but not 192 and 256,
> which the capabilities structure was reporting.
>
> Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
I think you mean
Fixes: 26c2e4ad5ad4 ("cryptodev: add capabilities discovery")
2016-04-07 00:09, Yuanhan Liu:
> On Wed, Apr 06, 2016 at 09:37:53AM +, Loftus, Ciara wrote:
> > > On Wed, Apr 06, 2016 at 03:49:25PM +0900, Tetsuya Mukawa wrote:
> > > > Hi,
> > > >
> > > > I appreciate fixing it.
> > > > Just one worry is that state changed event may be occurred before new
> >
2016-04-06 15:27, Olivier Matz:
> Seen while trying to fix the func_reentrancy autotest. The
> series addresses several issues:
>
> 1/ Hash and lpm return a pointer to an existing object if the user requests
> the
>creation with an already existing name. This look dangerous: when an object
>
If the vhost PMD were configured with more queues than the guest, the old
code would segfault in rte_vhost_enable_guest_notification due to a NULL
virtqueue pointer.
Fixes: ee584e9710b9 ("vhost: add driver on top of the library")
Signed-off-by: Rich Lane
---
drivers/net/vhost/rte_eth_vhost.c | 5
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, April 06, 2016 5:37 PM
> To: Trahe, Fiona
> Cc: dev at dpdk.org; Doherty, Declan
> Subject: Re: [dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label
>
> 2016-04-06 12:05, Fiona Trahe:
Hi Robert,
Sorry for my delay, I am traveling this week, I will reply as soon as I find a
slot to focus on this, hopefully in the next couple of days, thanks for your
patience.
Regards,
Cristian
> -Original Message-
> From: Sanford, Robert [mailto:rsanford at akamai.com]
> Sent: Friday
AES-GCM PMD only supports 128-bit keys, but not 192 and 256,
which the capabilities structure was reporting.
Fixes: 27cf2d1b18e1 ("examples/l2fwd-crypto: discover capabilities")
Signed-off-by: Pablo de Lara
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 8
1 file changed, 4 inserti
2016-04-06 11:51, Jianfeng Tan:
> This change is to make user code simpler. For PMDs which do not fill any
> packet types, return 0 instead of -ENOTSUP as suggested by Bruce.
>
> Usually, users only care if the required (by ptype_mask) ptypes can be
> filled by the specified PMD. If the PMD imple
On 2016/04/06 16:17, Yuanhan Liu wrote:
> On Wed, Apr 06, 2016 at 03:49:25PM +0900, Tetsuya Mukawa wrote:
>> On 2016/04/06 1:09, Ciara Loftus wrote:
>>> After some testing, it was found that retrieving numa information
>>> about a vhost device via a call to get_mempolicy is more
>>> accurate when p
Hi,
On 04/06/2016 08:07 AM, Panu Matilainen wrote:
>> +1: it's a bit weird to keep both, especially for a long while, that
>> every time we turn a rte_ prefix to dpdk_ prefix, we break applications.
>> Instead of breaking applications many times, I'd prefer to break once.
>> Therefore, application
Issue:
when using the following CLI in testpmd to enable ipv6 TSO feature
(set --txqflags=0 in the testpmd command)
set verbose 1
csum set ip hw 0
csum set udp hw 0
csum set tcp hw 0
csum set sctp hw 0
csum set outer-ip hw 0
csum parse_tunnel
On 2016/04/06 1:09, Ciara Loftus wrote:
> After some testing, it was found that retrieving numa information
> about a vhost device via a call to get_mempolicy is more
> accurate when performed during the new_device callback versus
> the vring_state_changed callback, in particular upon initial boot
2016-04-06 13:17, Ferruh Yigit:
> With (ICC) 16.0.2 20160204, getting following warnings:
>
> .../drivers/net/ena/base/ena_com.c(492): error #3656: variable
> "flags" may be used before its value is set
> ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
>
> .../drivers/net/ena/base/ena_com.c(19
> > We will not get what we want, the ipv6 packets sent out from IXIA can be
> > received by i40e, but cannot forward to another port.
> > The root cause is when HW doing the TSO offload for packets, it does not
> > only
> > depends on the context descriptor to define the MSS and TSO payload size,
2016-04-05 10:01, Jingjing Wu:
> The issue is the VF's link speed kept as 10G and status always was up.
> It did not change even the physical link's status changed.
> This patch fixes this issue to make VF's link info consistent with
> physical link.
>
> Fixes: 4861cde46116 (i40e: new poll mode dr
On Tue, Apr 05, 2016 at 05:37:05PM -0700, Rasesh Mody wrote:
> Signed-off-by: Harish Patil
> Signed-off-by: Rasesh Mody
> ---
> doc/guides/nics/bnx2x.rst|1 +
> doc/guides/nics/overview.rst | 22 +++---
> 2 files changed, 12 insertions(+), 11 deletions(-)
>
Thanks for
The previous code in func_reentrancy autotest was doing in parallel
something close to:
name = "common_name";
do several times {
obj = allocate_an_object(name) // obj = ring, mempool, hash, lpm, ...
if (obj == NULL && lookup(name) == NULL)
return TEST_FAIL;
}
This co
To avoid a race condition while creating a new hash object, the
list has to be locked before the lookup, and released only once the
new object is added in the list.
As the lock is held by the rte_ring_create(), move its creation at the
beginning of the function and only take the lock after the rin
Change rte_hash*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the c
Change rte_lpm*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the ca
Seen while trying to fix the func_reentrancy autotest. The
series addresses several issues:
1/ Hash and lpm return a pointer to an existing object if the user requests the
creation with an already existing name. This look dangerous: when an object
is returned, the user does not know if it sh
Over a year ago, Neil pointed out that calling netif_rx() from
kni_net_rx_normal() was a bug and could cause lockups. Here's the comment:
http://dpdk.org/ml/archives/dev/2015-March/015783.html
Looking at the current code base, it is still calling netif_rx() instead of
netif_rx_ni() as suggested.
On Wed, Apr 06, 2016 at 03:49:25PM +0900, Tetsuya Mukawa wrote:
> On 2016/04/06 1:09, Ciara Loftus wrote:
> > After some testing, it was found that retrieving numa information
> > about a vhost device via a call to get_mempolicy is more
> > accurate when performed during the new_device callback ver
I had a system lockup hard a couple of days ago and all we were able to get
was a photo of the LCD monitor with most of the kernel panic on it. No way
to scroll back the buffer and nothing in the logs after we rebooted. Not
surprising with a kernel panic due to an exception during interrupt
process
On 04/06/2016 08:26 AM, Yuanhan Liu wrote:
> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
>> On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona
>> wrote:
>>
>>>
>>>
-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
Sen
We currently exposed way too many fields (or even structures) than
necessary. For example, vhost_virtqueue struct should NOT be exposed
to user at all: application just need to tell the right queue id to
locate a specific queue, and that's all. Instead, the structure should
be defined in an interna
On 05/04/2016 18:58, Harry van Haaren wrote:
> This patch adds a notice that the API for the xstats
> functionality will be modified in the 16.07 release, with
> no backwards compatibility planned as it would require
> code duplication in each PMD that supports xstats.
>
> Signed-off-by: Harry van
>On 04/06/2016 08:26 AM, Yuanhan Liu wrote:
>> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
>>> On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona
>>> wrote:
>>>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Rasesh Mody
> Subject: [dpdk-dev] [PATCH v3 3/4] bnx2x: Enhance stats get
Hi Rasesh,
> + snprintf(xstats[num].name, sizeof(xstats[num].name), "brb_drops");
I don't understand what a "brb" drop is.
> + snprintf(xstats[num].name,
On 4/6/2016 2:17 PM, Yuanhan Liu wrote:
> On Wed, Apr 06, 2016 at 02:05:51PM +0800, Tan, Jianfeng wrote:
>>
>> On 4/6/2016 1:44 PM, Yuanhan Liu wrote:
>>> On Wed, Apr 06, 2016 at 01:32:12PM +0800, Tan, Jianfeng wrote:
Hi,
Just out of interest, seems that the message handling thread
> From: Van Haaren, Harry
> Sent: Tuesday, April 5, 2016 6:58 PM
> To: dev at dpdk.org
> Cc: Tahhan, Maryam ; Van Haaren, Harry
>
> Subject: [PATCH] doc: announce xstats api change for 16.07
>
> This patch adds a notice that the API for the xstats functionality will be
> modified in the 16.07 rel
On Wed, Apr 06, 2016 at 02:05:51PM +0800, Tan, Jianfeng wrote:
>
>
> On 4/6/2016 1:44 PM, Yuanhan Liu wrote:
> >On Wed, Apr 06, 2016 at 01:32:12PM +0800, Tan, Jianfeng wrote:
> >>Hi,
> >>
> >>Just out of interest, seems that the message handling thread which runs
> >>new_device() is pthread_creat
This patch updates the titles in the multiprocess memory image
to read "Primary Process" and "Secondary Process" instead of
"DPDK Server Process" and "Customer Client Process".
The rest of the image has been converted from PNG to SVG.
Signed-off-by: Harry van Haaren
---
PS: Have to send this p
2016-04-06 11:16, Van Haaren, Harry:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > The issue we are going to fix is that currently PMDs copy strings when
> > > retrieving
> > statistics, which causes unnecessary overhead. The implementation is not
> > decided yet, but
> > us
On Wed, 6 Apr 2016 10:54:14 +0200
Adrien Mazarguil wrote:
> Hi Jan,
>
> Replying below as well.
>
[...]
> > > --- a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> > > +++ b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> > > @@ -37,6 +37,9 @@
> > > # error Platform must be
On 4/6/2016 1:44 PM, Yuanhan Liu wrote:
> On Wed, Apr 06, 2016 at 01:32:12PM +0800, Tan, Jianfeng wrote:
>> Hi,
>>
>> Just out of interest, seems that the message handling thread which runs
>> new_device() is pthread_create() from the thread which calls the
>> dev_start(), usually master thread,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Harry van Haaren
> Sent: Tuesday, April 05, 2016 1:58 PM
> To: dev at dpdk.org
> Cc: maryam.tahhan at intel.com; Harry van Haaren intel.com>
> Subject: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.
On 04/06/2016 01:20 PM, De Lara Guarch, Pablo wrote:
>> On 04/06/2016 12:32 PM, De Lara Guarch, Pablo wrote:
>>>
>>> I wonder if you should include something in release notes.
>>> We are fixing the API, so I guess we don't need to follow the deprecation
>> process, but at least a note in the docu
> From: David Harton (dharton) [mailto:dharton at cisco.com]
> Subject: RE: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
> > This should not be the normal process.
> > It is important to understand what should be the changes to decide of
> > announcing or not a deprecation.
> > In t
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, April 06, 2016 8:14 AM
> To: Van Haaren, Harry
> Cc: David Harton (dharton) ; dev at dpdk.org; Tahhan,
> Maryam ; olivier.matz at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH] doc: announc
On Wed, Apr 06, 2016 at 01:32:12PM +0800, Tan, Jianfeng wrote:
> Hi,
>
> Just out of interest, seems that the message handling thread which runs
> new_device() is pthread_create() from the thread which calls the
> dev_start(), usually master thread, right? But it's not necessary to be the
> master
On Wed, Apr 06, 2016 at 05:11:01AM +, Ilya Maximets wrote:
> > There is a plan to use vHost PMD, so from OVS point of view the virtio
> > stuff would be hidden because vhost PMD would look like just as a
> > regular ethernet, right?
>
> But we still need to have access to virtqueue_enabe/disab
Hi,
Just out of interest, seems that the message handling thread which runs
new_device() is pthread_create() from the thread which calls the
dev_start(), usually master thread, right? But it's not necessary to be
the master thread to poll pkts from this vhost port, right? So what's
the signifi
On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
> On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona wrote:
>
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > > Sent: Tuesday, April 05, 2016 2:57 PM
> > > To: de
With (ICC) 16.0.2 20160204, getting following warnings:
.../drivers/net/ena/base/ena_com.c(492): error #3656: variable
"flags" may be used before its value is set
ENA_SPINLOCK_LOCK(admin_queue->q_lock, flags);
.../drivers/net/ena/base/ena_com.c(1971): error #3656: variable
"mem_handle" may b
On 04/06/2016 12:32 PM, De Lara Guarch, Pablo wrote:
>
> I wonder if you should include something in release notes.
> We are fixing the API, so I guess we don't need to follow the deprecation
> process, but at least a note in the documentation?
Good idea, I'll send a v4 with the deprecation no
On Tue, Apr 05, 2016 at 05:09:47PM +0100, Ciara Loftus wrote:
> After some testing, it was found that retrieving numa information
> about a vhost device via a call to get_mempolicy is more
> accurate when performed during the new_device callback versus
> the vring_state_changed callback, in particu
On Wed, Apr 06, 2016 at 01:14:09AM -0300, Flavio Leitner wrote:
> >
> > I'd vote for this one, as it sounds very clean to me. This would also
> > solve the block issue of this patch. Though it would break OVS, I'm thinking
> > that'd be okay, as OVS has dependence on DPDK version: what we need to
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> Sent: Wednesday, April 6, 2016 1:41 PM
> To: Yuanhan Liu
> Cc: Arnon Warshavsky ; Trahe, Fiona
> ; Thomas Monjalon ;
> dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK namespace
>
> On Wed, Apr 6,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, April 06, 2016 1:08 PM
> To: Yuanhan Liu; Arnon Warshavsky
> Cc: Trahe, Fiona; Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK namespace
>
> On 04/06/2016 08:
> A problem is found on i350 VF. We found TX will happen once
> per 4 packets. If only 1~3 packets are received, they will
> not be forwarded. But the real problem is on RX side. The
> reason is the default RX write-back threshold is changed to
> 4, so every first 3 packets may be hung there.
>
>
> > For simple TX the virtio-net header must be zeroed, but it was using memory
> > that had been initialized with indirect descriptor tables. This resulted in
> > "unsupported gso type" errors from librte_vhost.
> >
> > We can use the same memory for every descriptor to save cachelines in the
> >
On Wed, 06 Apr 2016 12:05:31 +0200
Thomas Monjalon wrote:
> Hi Jan,
>
> 2016-04-06 11:53, Jan Viktorin:
> > Please, see the attached log file.
>
> The text attachments are filtered out on the mailing list because
> it is not convenient or impossible to read in the archives.
> Please use inlin
> Fix following coverity defect:
>
> 291 void
> 292 vhost_destroy_device(struct vhost_device_ctx ctx)
> 293 {
> 294 struct virtio_net *dev = get_device(ctx);
> 295
> >>> CID 124565: Null pointer dereferences (NULL_RETURNS)
> >>> Derefer
2016-04-05 11:06, Van Haaren, Harry:
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> > Subject: [dpdk-dev] [PATCH] xstats: fix behavior when a null array is
> > provided
> >
> > Coverity reports an issue in ethdev:
> >
> > *** CID 124562: Null pointer dereferences
> > The hash test (located in group_2) may require more than 64MB of memory,
> > especially if the memory is physically fragmented, making the test to
> > fail. So increase the memory to 128MB to avoid this issue.
> >
> > Signed-off-by: Olivier Matz
>
> Acked-by: Pablo de Lara
Applied, thanks
Hi Jan,
2016-04-06 11:53, Jan Viktorin:
> Please, see the attached log file.
The text attachments are filtered out on the mailing list because
it is not convenient or impossible to read in the archives.
Please use inline text, next time. Thanks
The cryptodev API was introduced in the DPDK 2.2 release.
Since then it has
- been reviewed and iterated for the DPDK 16.04 release
- had extensive use by the l2fwd-crypto app,
the ipsec-secgw example app,
the test app.
We believe it is now stable a
> > Since commit a88ba49e51, values larger than 4 are allowed,
> > the autotests need to be updated accordingly.
> >
> > Fixes: a88ba49e51 ("config: fix CPU and memory parameters on IBM
> > POWER8")
> > Signed-off-by: Olivier Matz
>
> Acked-by: Pablo de Lara
Hello Adrien,
I've failed to build the patch set
[PATCH 00/10] Fix build errors related to exported headers
properly. Please, see the attached log file. It's something with a
header file inclusion. It should be probably:
#include "rte_ether.h"
Regards
Jan
--
Jan Viktorin
This change is to make user code simpler. For PMDs which do not fill any
packet types, return 0 instead of -ENOTSUP as suggested by Bruce.
Usually, users only care if the required (by ptype_mask) ptypes can be
filled by the specified PMD. If the PMD implements dev_supported_ptypes_get
func is not
2016-04-06 09:16, Weglicki, MichalX:
> Hello,
>
> Thank you for your answer.
>
> I didn't mention that patch is cosmetic, rather naming.
>
> But all clear, I somehow missed it 9 months ago, and couldn't find it.
>
> Is there any official place where I can find upcoming ABI & API changes, or
> > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet grouping
> > algorithm.
> >
> > When last packet pointer "lp" and "pnum->u64" buffer points the same
> > memory buffer, high optimization can cause unpredictable results. It seems
> > that assignment of precalculated group size
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhe Tao
> Sent: Wednesday, April 06, 2016 9:17 AM
> To: dev at dpdk.org
> Cc: Tao, Zhe; Wu, Jingjing
> Subject: [dpdk-dev] [PATCH v4] i40e: fix TSO issue for tx function
>
> Issue:
>
> when using the followin
2016-04-06 09:02, Van Haaren, Harry:
> + David Harton,
>
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Subject: Re: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
> > 2016-04-05 18:58, Harry van Haaren:
> > > +* ABI change is planned for the xstats API
>
> > Ha
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, April 06, 2016 12:15 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Cc: Richardson, Bruce
> Subject: Re: [dpdk-dev] [PATCH v3 0/4] fix creation of duplicate lpm and hash
>
>
>
> On 04/06/
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Subject: Re: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
> > The issue we are going to fix is that currently PMDs copy strings when
> > retrieving
> statistics, which causes unnecessary overhead. The implementation is
2016-04-05 11:31, Jianfeng Tan:
> Update the overview.rst for virtio.
>
> Note: virtio is a para-virtualization device, which indicates that its
> features depend on not only front end but also back end. Here by X, we
> just mean the feature is supported in front end.
>
> Signed-off-by: Jianfeng
Hi Jan,
Replying below as well.
On Tue, Apr 05, 2016 at 10:23:04PM +0200, Jan Viktorin wrote:
> Hello Adrien,
>
> just quickly skimming through the ARM fixes...
>
> On Tue, 5 Apr 2016 16:08:07 +0200
> Adrien Mazarguil wrote:
>
> > Exported header files for use by applications should be self
2016-04-06 08:34, Weglicki, MichalX:
> Hello,
>
> I have a question about this patch.
>
> As far as I see changing ETH_LINK_SPEED_ to ETH_SPEED_NUM_ is rather cosmetic
> change, am I right?
No.
ETH_LINK_SPEED was used for configuration and reported speed.
Now the configuration is done with a
2016-04-05 11:46, John Daley:
> usage docX X X
> X
doc/guides/nics/enic.rst ?
I'll fill "usage doc".
Applied, thanks
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, April 5, 2016 4:48 PM
> To: Iremonger, Bernard
> Cc: dev at dpdk.org; Lu, Wenzhuo
> Subject: Re: [dpdk-dev] [PATCH v2] ixgbe: fix occasional timeouts when
> starting VF
>
> 201
2016-04-01 16:55, Chen Jing D:
> - stats per queue X
> X
> + stats per queue X
> X
I think you should fill "stats per queue"
> BSD nic_uio X X X X
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, April 05, 2016 12:54 PM
> To: dev at dpdk.org
> Cc: Richardson, Bruce; De Lara Guarch, Pablo
> Subject: [dpdk-dev] [PATCH v3 0/4] fix creation of duplicate lpm and hash
>
> Seen w
2016-04-05 10:54, Wenzhuo Lu:
> Update the overview.rst for e1000, igb, ixgbe.
>
> v2:
> - Some "X"s are put in the wrong place, correct it.
>
> Signed-off-by: Wenzhuo Lu
Applied, thanks
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, April 05, 2016 4:52 PM
> To: Richardson, Bruce; De Lara Guarch, Pablo
> Cc: dev at dpdk.org; Olivier Matz
> Subject: Re: [dpdk-dev] [PATCH v3 0/4] fix creation of duplicate lpm and hash
>
>
> On Wed, Apr 06, 2016 at 03:49:25PM +0900, Tetsuya Mukawa wrote:
> > On 2016/04/06 1:09, Ciara Loftus wrote:
> > > After some testing, it was found that retrieving numa information
> > > about a vhost device via a call to get_mempolicy is more
> > > accurate when performed during the new_device
Hello,
Thank you for your answer.
I didn't mention that patch is cosmetic, rather naming.
But all clear, I somehow missed it 9 months ago, and couldn't find it.
Is there any official place where I can find upcoming ABI & API changes, or I
have to dig through mailing list?
Thank you in ad
+ David Harton,
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Subject: Re: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
> 2016-04-05 18:58, Harry van Haaren:
> > +* ABI change is planned for the xstats API
> Have you already submitted a RFC patch to let us have a
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Fan Zhang
> > Sent: Thursday, March 31, 2016 2:29 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] [PATCH] doc: announce ABI change for
> > rte_port_source_params structure
> >
> > Several new fields will b
Hello,
I have a question about this patch.
As far as I see changing ETH_LINK_SPEED_ to ETH_SPEED_NUM_ is rather cosmetic
change, am I right?
Disadvantage of that is that it breaks compatibility with OVS (compilation) and
thus it also breaks backward compatibility between OVS & DPDK. Is it r
On Wed, Apr 6, 2016 at 12:26 AM, Yuanhan Liu
wrote:
> On Tue, Apr 05, 2016 at 05:31:22PM +0300, Arnon Warshavsky wrote:
> > Googling rte functions or error codes usually takes you to dpdk dev email
> > archive so I don't think it is that much difficult to figure out where
> rte
> > comes from.
>
--- Original Message ---
Sender : Yuanhan Liu
Date : Apr 06, 2016 08:38 (GMT+03:00)
Title : Re: Re: [RFC] vhost-user public struct refactor (was Re: [dpdk-dev]
[PATCH RFC 2/4] vhost: make buf vector for scatter RX) local.
On Wed, Apr 06, 2016 at 05:11:01AM +, Ilya Maximets wrote:
> >
--- Original Message ---
Sender : Flavio Leitner
Date : Apr 06, 2016 07:14 (GMT+03:00)
Title : Re: [RFC] vhost-user public struct refactor (was Re: [dpdk-dev] [PATCH
RFC 2/4] vhost: make buf vector for scatter RX) local.
On Tue, Apr 05, 2016 at 01:47:33PM +0800, Yuanhan Liu wrote:
> On Fr
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, April 5, 2016 9:56 AM
> To: Lu, Wenzhuo
> Cc: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting
>
2016-04-05 10:54, Wenzhuo Lu:
> Update the overview.rst for e1000, igb, ixgbe.
[...]
> stats per queue X
> X
You have not filled stats per queue. Is it because of an issue
with queue_stats_mapping?
[...]
> usage doc
On Tue, Apr 05, 2016 at 01:47:33PM +0800, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 03:06:50PM +0800, Yuanhan Liu wrote:
> > On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
> > > Array of buf_vector's is just an array for temporary storing information
> > > about available descrip
96 matches
Mail list logo
