Hi,
> Subject: Re: [dpdk-dev] DPDK doesn't work with iommu=pt
>
> iommu=pt effectively disables iommu for the kernel and iommu is
> enabled only for KVM.
> http://lwn.net/Articles/329174/
thanks for pointing that.
Okay, I think DPDK cannot handle IOMMU because of no kernel code in
DPDK applicat
Hi,
> Subject: RE: DPDK doesn't work with iommu=pt
>
> Met the similar issue before.
> VT-d enabled? If so you may need to contact HP to upgrade the BIOS or you may
> disable VT-d and remove iommu=pt intel_iommu=on
> if you don't need VF function.
we need VT-d and it's enabled.
What we want to
On Sep 28, 2014, at 5:41 PM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Roger Keith
>> Sent: Sunday, September 28, 2014 6:52 PM
>> To:
>> Subject: [dpdk-dev] [RFC] More changes for rte_mempool.h:__mempool_get_
Thanks Venky,
On Sep 28, 2014, at 5:23 PM, Venkatesan, Venky
wrote:
> Keith,
>
> On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote:
>> I am also looking at the bulk dequeue routines, which the ring can be fixed
>> or variable. On fixed < 0 on error is returned and 0 if successful. On a
>> vari
> -Original Message-
> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> Sent: Sunday, September 28, 2014 11:57 PM
> To: Ananyev, Konstantin
> Cc:
> Subject: Re: [dpdk-dev] [PATCH] Function __mempool_get_bulk() returns wrong
> count.
>
>
> On Sep 28, 2014, at 5:25 PM, A
On Sep 28, 2014, at 5:25 PM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Roger Keith
>> Sent: Saturday, September 27, 2014 7:42 PM
>> To:
>> Subject: [dpdk-dev] [PATCH] Function __mempool_get_bulk() returns wro
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Roger Keith
> Sent: Sunday, September 28, 2014 6:52 PM
> To:
> Subject: [dpdk-dev] [RFC] More changes for rte_mempool.h:__mempool_get_bulk()
>
> Here is a Request for Comment on __mempool_get_bulk() ro
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Roger Keith
> Sent: Saturday, September 27, 2014 7:42 PM
> To:
> Subject: [dpdk-dev] [PATCH] Function __mempool_get_bulk() returns wrong count.
>
>
> When __mempool_get_bulk() grabs entries from the c
Agree with NACK. This type of string matching won't scale.
THe better way is to encapsulate required behavior in feature flags.
I started that with drv_flags, and that seems natural home for such device
specific stuff.
On Sun, Sep 28, 2014 at 5:36 AM, Neil Horman wrote:
> On Sun, Sep 28, 2014 at
One of the DPDK demos that comes closer to the description here is
http://www.advantech.com/networks-telecom/News.aspx?doc_id=BFEDE586-0FDC-4600-B808-3C09FBE6F910
However, this does not have detailed info.
Will see what additional info. we can get on this.
Thanks
-Original Message-
Fro
On Sun, Sep 28, 2014 at 03:23:44PM -0700, Venkatesan, Venky wrote:
> Keith,
>
> On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote:
> >I am also looking at the bulk dequeue routines, which the ring can be fixed
> >or variable. On fixed < 0 on error is returned and 0 if successful. On a
> >variable
I am also looking at the bulk dequeue routines, which the ring can be fixed or
variable. On fixed < 0 on error is returned and 0 if successful. On a variable
ring < 0 on error or n on success, but I think n can be zero in the variable
case, correct?
If these are true then why not have the rout
Here is a Request for Comment on __mempool_get_bulk() routine. I believe I am
seeing a few more issues in this routine, please look at the code below and see
if these seem to fix some concerns in how the ring is handled.
The first issue I believe is cache->len is increased by ret and not req as
On Sun, Sep 28, 2014 at 04:12:04PM +, Ananyev, Konstantin wrote:
>
>
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, September 26, 2014 8:39 PM
> > To: Ananyev, Konstantin
> > Cc: Wodkowski, PawelX; dev at dpdk.org
> > Subject: Re: [dpd
On Sun, Sep 28, 2014 at 06:04:42PM +, Wiles, Roger Keith wrote:
> I am also looking at the bulk dequeue routines, which the ring can be fixed
> or variable. On fixed < 0 on error is returned and 0 if successful. On a
> variable ring < 0 on error or n on success, but I think n can be zero in
On Sun, Sep 28, 2014 at 05:52:16PM +, Wiles, Roger Keith wrote:
> Here is a Request for Comment on __mempool_get_bulk() routine. I believe I am
> seeing a few more issues in this routine, please look at the code below and
> see if these seem to fix some concerns in how the ring is handled.
>
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, September 26, 2014 8:39 PM
> To: Ananyev, Konstantin
> Cc: Wodkowski, PawelX; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to
> thread-safe:
>
> On Fri, Sep 26
Keith,
On 9/28/2014 11:04 AM, Wiles, Roger Keith wrote:
> I am also looking at the bulk dequeue routines, which the ring can be fixed
> or variable. On fixed < 0 on error is returned and 0 if successful. On a
> variable ring < 0 on error or n on success, but I think n can be zero in the
> vari
From: Zhida Zang
Add support of link flow control.
Signed-off-by: Zhida Zang
Acked-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 216 +-
lib/librte_pmd_i40e/i40e_ethdev.h | 1 +
2 files changed, 214 insertions(+), 3 deletions(-)
diff --git a/li
On Sep 28, 2014, at 7:27 AM, Neil Horman wrote:
> On Sun, Sep 28, 2014 at 05:28:44AM +, Wiles, Roger Keith wrote:
>>
>> Check the FILE *f and rte_mempool *mp pointers for NULL and
>> return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
>>
>> Signed-off-by: Keith Wiles
>
the right shift bits should be 5 rather than 4.
vid_idx = (uint32_t) ((vlan_id >> 5 ) & 0x7F)
Signed-off-by: Huawei Xie
CC: Jing Chen
CC: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_e
As different PMDs support different features, application may want
to know the NIC type of a port, then decide how to use that port.
Add a new field in struct rte_eth_dev, users are able to get
device type now.
Signed-off-by: Ding Heng
---
lib/librte_ether/rte_ethdev.c | 32 +
i40e PMD divide queues among MAIN VSI and VMDQ VSI. The queue index and pool
index doesn't start from zero.
Get VMDQ queue base and pool base from rte_eth_dev_info_get.
Currently we set up all queues including pf queues. If PMD supports, we could
only set up queues we use.
Signed-off-by: Huawei
Queues in i40e are comprised of main vsi queues and VMDQ vsi queues.
The queue index and pool index of VMDQ doesn't start from zero.
Huawei Xie (1):
support i40e in vhost example
examples/vhost/main.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
--
iommu=pt effectively disables iommu for the kernel and iommu is
enabled only for KVM.
http://lwn.net/Articles/329174/
Basically unless you have KVM running you can remove both lines for
the same effect.
On the other hand if you do have KVM and you do want iommu=on You can
remove the iommu=pt for t
LSO/TSO support is an important feature, I'm surprised its not
supported in DPDK.
I personally would like to see these patches.
On Fri, Sep 26, 2014 at 1:23 PM, Vadim Suraev wrote:
> Hi, all,
> I found ixgbe in couple with rte_mbuf (and probably other PMD drivers)
> don't support GSO, I reverse
Even IF only the Demo is available it would be useful.
I assume the people behind the Demo are pert of this mailing list (Or
someone on the mailing list knows them).
It would be great if the demo was publicly available anywhere.
On Thu, Sep 25, 2014 at 11:09 PM, Matthew Hall wrote:
> On Thu, Sep
On Sun, Sep 28, 2014 at 07:39:57AM +, Zhang, Jerry wrote:
> Hi all,
>
> Do you know why DPDK(shared library) constructor function
> rte_cpu_check_supported() needs to check some unnecessary CPU flags which is
> not used by current DPDK such as "AES"?
>
> On Hehalem platform
On Sun, Sep 28, 2014 at 11:27:16AM +0800, Ding Heng wrote:
> As different PMDs support different features, application may want
> to know the NIC type of a port, then decide how to use that port.
> Add a new field in struct rte_eth_dev, users are able to get
> device type now.
>
> Signed-off-by: D
On Sun, Sep 28, 2014 at 05:28:44AM +, Wiles, Roger Keith wrote:
>
> Check the FILE *f and rte_mempool *mp pointers for NULL and
> return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
>
> Signed-off-by: Keith Wiles
> ---
> lib/librte_mempool/rte_mempool.c | 3 +++
> 1 file
On Sun, Sep 28, 2014 at 05:38:06AM +, Wiles, Roger Keith wrote:
>
> On Sep 27, 2014, at 8:55 PM, Neil Horman wrote:
>
> > On Sun, Sep 28, 2014 at 01:14:05AM +, Wiles, Roger Keith wrote:
> >>
> >> On Sep 27, 2014, at 7:37 PM, Neil Horman wrote:
> >>
> >>> On Sat, Sep 27, 2014 at 06:35:
Met the similar issue before.
VT-d enabled? If so you may need to contact HP to upgrade the BIOS or you may
disable VT-d and remove iommu=pt intel_iommu=on if you don't need VF function.
>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Hiroshi Shimamoto
>Sent:
Hi all,
Do you know why DPDK(shared library) constructor function
rte_cpu_check_supported() needs to check some unnecessary CPU flags which is
not used by current DPDK such as "AES"?
On Hehalem platform with GCC4.8, using shard DPDK library, it will report
AES is not supported. Bu
On Sep 27, 2014, at 8:55 PM, Neil Horman wrote:
> On Sun, Sep 28, 2014 at 01:14:05AM +, Wiles, Roger Keith wrote:
>>
>> On Sep 27, 2014, at 7:37 PM, Neil Horman wrote:
>>
>>> On Sat, Sep 27, 2014 at 06:35:01PM +, Wiles, Roger Keith wrote:
Check the FILE *f and rte_mempool *
When enabling RTE_LIBRTE_MEMPOOL_DEBUG and compiling with clang
compiler an error occurs, because ifdefed code now includes GCC pragmas.
GCC 4.4 is when push_options and pop_options pragma show up.
Signed-off-by: Keith Wiles
---
lib/librte_mempool/rte_mempool.h | 4 ++--
1 file changed, 2 inse
Check the FILE *f and rte_mempool *mp pointers for NULL and
return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
Signed-off-by: Keith Wiles
---
lib/librte_mempool/rte_mempool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librt
Hi Patel,
The customer consider that deploy DPDK application in Amazon VMs is very
flexible and very easy global site deployment:
such as: they only need to buy a 2 lcores VM if a site only need 200Mbps
throughput; buy one 4 lcores VM if the throughput is 400Mbps;
the can buy different Ama
Acked-by: Helin Zhang
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ding Heng
> Sent: Sunday, September 28, 2014 11:27 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ethdev: The users could get device types now
>
> As different PMDs support differ
On Sep 27, 2014, at 7:37 PM, Neil Horman wrote:
> On Sat, Sep 27, 2014 at 06:35:01PM +, Wiles, Roger Keith wrote:
>>
>> Check the FILE *f and rte_mempool *mp pointers for NULL and
>> return plus print out a message if RTE_LIBRTE_MEMPOOL_DEBUG is enabled.
>>
>> Signed-off-by: Keith Wiles
>
OK, let me look at RTE_VERIFY then and will send a new patch.
On Sep 27, 2014, at 7:37 PM, Neil Horman wrote:
> On Sat, Sep 27, 2014 at 06:35:01PM +, Wiles, Roger Keith wrote:
>>
>> Check the FILE *f and rte_mempool *mp pointers for NULL and
>> return plus print out a message if RTE_LIBRTE_
Self nack this one :-(. It looks like the code should be something like this
instead:
#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))
#pragma GCC push_options
#pragma GCC diagnostic ignored "-Wcast-qual"
#endif
GCC 4.4 is when push_options and pop_options showed up in GCC. I wil
41 matches
Mail list logo
