[dpdk-dev] [PATCH 1/6] ixgbe: Support VMDq RSS in non-SRIOV environment

Hi Michael, Pls review the latest version (v4). Thanks for your effort Changchun > -Original Message- > From: Qiu, Michael > Sent: Monday, August 24, 2015 6:42 PM > To: Ouyang, Changchun; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/6] ixgbe: Support VMDq RSS in non-SRIOV > enviro

[dpdk-dev] vhost compliant virtio based networking interface in container

Hi Xie and Yanping, May I ask you some questions? It seems we are also developing an almost same one. On 2015/08/20 19:14, Xie, Huawei wrote: > Added dev at dpdk.org > > On 8/20/2015 6:04 PM, Xie, Huawei wrote: >> Yanping: >> I read your mail, seems what we did are quite similar. Here i wrote a

[dpdk-dev] Why the offloads of the guest's virtio-net network adapter are disabled when vhost-user is used?

On 2015/08/24 22:09, leo zhu wrote: > Hi all, > > I am running the vhost sample application on my server. > > According to the dpdk-sample-applications-user-guide.pdf, I run the Virtual > Machine with vhost-user enabled. > Following is the command that is used to run the virtual machine. > > > > >

[dpdk-dev] Why the offloads of the guest's virtio-net network adapter are disabled when vhost-user is used?

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa > Sent: Tuesday, August 25, 2015 11:23 AM > To: leo zhu; dev at dpdk.org > Subject: Re: [dpdk-dev] Why the offloads of the guest's virtio-net network > adapter are disabled when vhost-user is use

[dpdk-dev] Why the offloads of the guest's virtio-net network adapter are disabled when vhost-user is used?

Hi Tetsuya & Jijiang, Great! Thanks a lot for your explanations. Thanks. Leo On Tue, Aug 25, 2015 at 11:27 AM, Liu, Jijiang wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa > > Sent: Tuesday, August 25, 2015 11:23 AM > > To: l

[dpdk-dev] vhost compliant virtio based networking interface in container

On 8/25/2015 10:59 AM, Tetsuya Mukawa wrote: > Hi Xie and Yanping, > > > May I ask you some questions? > It seems we are also developing an almost same one. Good to know that we are tackling the same problem and have the similar idea. What is your status now? We had the POC running, and compliant

[dpdk-dev] [PATCH 3/3] app/test: enable test_red to build on non x86 platform

2015-08-18 18:10, Jerin Jacob: > --- a/app/test/test_red.c > +++ b/app/test/test_red.c > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) || > defined(RTE_ARCH_X86_X32) > #ifdef __PIC__ > asm volatile ( > "mov %%ebx, %%edi\n" > @@ -155,6 +156,7 @@ static inline void rdtsc_prof_st

[dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD

2015-08-18 16:55, Ian Stokes: > The qos_meter sample app will fail to compile if APP_MODE > is set to APP_MODE_FWD. This patch changes the variable > name 'color' in main.h to the expected variable name > 'input_color' to allow compilation with APP_MODE_FWD. Thanks for raising the issue. > --- a/

[dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD

> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, August 25, 2015 1:37 PM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD > > > --- a/examples/qos_meter/main.h > > +++ b/exa

[dpdk-dev] [PATCH] qos_meter: Fix compilation with APP_MODE_FWD

2015-08-25 13:34, Mcnamara, John: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > This patch should not be accepted to discourage build-time options. > > Patch for run-time option is welcome. > > The patch is fixing a compilation issue, which seems reasonable. It isn'

[dpdk-dev] working example commands for ethertype/flow_director_filter ?

Hi, If you use "help filters", you can probably get the command format like: ethertype_filter (port_id) (add|del) (mac_addr|mac_ignr) (mac_address) ethertype (ether_type) (drop|fwd) queue (queue_id) Add/Del an ethertype filter. > -Original Message- > From: dev [mailto:dev-bounces at

[dpdk-dev] flow_director_filter error!!

Hi, Navneet I'm sorry for I have no idea about the NIC i540. Are you talking about X540? If X540, I guess you can't classify on the MAC-ADDRESS to different queue by ethertype filter. Because in the X540 datasheet the ethertype filter is described as below: " 7.1.2.3 L2 Ethertype Filters These f

[dpdk-dev] Industry's Tiny and Powerful Wireless LAN Controller - Running On Intel NUC D34010WYKH - Built on DPDK

Hi, We DO have plans to Open Source the entire Controller, not just the Data Plane, in the near future. Regards Venkat www.onehopnetworks.com On 19 August 2015 at 02:02, Thomas F Herbert wrote: > > > On 8/18/15 12:50 PM, Stephen Hemminger wrote: > >> On Tue, 18 Aug 2015 13:33:00 +0530 >> Ven

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

Hi Vlad, > -Original Message- > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Thursday, August 20, 2015 10:07 AM > To: Ananyev, Konstantin; Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for > all NICs bu

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 08/25/2015 08:33 PM, Ananyev, Konstantin wrote: > Hi Vlad, > >> -Original Message- >> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] >> Sent: Thursday, August 20, 2015 10:07 AM >> To: Ananyev, Konstantin; Lu, Wenzhuo >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v

[dpdk-dev] [PATCH v2] Change rte_eal_vdev_init to update port_id

Hi Thomas, David Let us know how you want us to fix this? To fix rte_eal_vdev_init and rte_eal_pci_probe_one to return allocated port_id we had 2 approaches mentioned in earlier discussion. In addition to those we have another approach with changes isolated only to rte_ether component. I am attach

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

Hi Vlad In addition, I?d double check with you what?s the maximum number of descriptors would be used for a single packet transmitting? Datasheet said that it supports up to 8. I am wondering if more than 8 were used in your case? Thank you very much! Regards, Helin From: Zhang, Helin Sent: We

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On Aug 25, 2015 21:14, "Zhang, Helin" wrote: > > Hi Vlad > > > > In addition, I?d double check with you what?s the maximum number of descriptors would be used for a single packet transmitting? > > Datasheet said that it supports up to 8. I am wondering if more than 8 were used in your case? If me

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

Hi Vlad I think this could possibly be the root cause of your TX hang issue. Please try to limit the number to 8 or less, and then see if the issue will still be there or not? It does not have any check for the number of descriptors to be used for a single packet, and it relies on the users to

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 08/25/15 21:43, Zhang, Helin wrote: > > Hi Vlad > > I think this could possibly be the root cause of your TX hang issue. > Please try to limit the number to 8 or less, and then see if the issue > will still be there or not? > Helin, the issue has been seen on x540 devices. Pls., see a chapt

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

> -Original Message- > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Tuesday, August 25, 2015 11:53 AM > To: Zhang, Helin > Cc: Lu, Wenzhuo; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for > all NICs but 82598 > > >

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 08/25/2015 10:16 PM, Zhang, Helin wrote: > >> -Original Message- >> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] >> Sent: Tuesday, August 25, 2015 11:53 AM >> To: Zhang, Helin >> Cc: Lu, Wenzhuo; dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On Aug 25, 2015 22:16, "Zhang, Helin" wrote: > > > > > -Original Message- > > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > > Sent: Tuesday, August 25, 2015 11:53 AM > > To: Zhang, Helin > > Cc: Lu, Wenzhuo; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd:

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

On 08/25/15 22:30, Vladislav Zolotarov wrote: > > > On Aug 25, 2015 22:16, "Zhang, Helin" > wrote: > > > > > > > > > -Original Message- > > > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com > ] > > > Sent:

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

Yes, I got the perfect answers. Thank you very much! I just wanted to make sure the test case was OK with the limit of maximum number of descriptors, as I heard there is a hang issue on other NICs of using more descriptors than hardware allowed. OK. I am still waiting for the answers/confirmation

[dpdk-dev] flow_director_filter error!!

Hi Jingjing: Thanks. I did have the ethertype_filter ignore the mac_addr, and look at only ethertype filtyer and it still got a "bad arguments" message :-( testpmd> ethertype_filter 0 add mac_ignr ethertype 0x0806 fwd queue 1 Bad arguments -Original Message- From: Wu, Jingjing [mai