[dpdk-dev] [PATCH] enic: fix vlan filtering
On 30/10/15 9:43 pm, "David Marchand" wrote:
>From: Julien Meunier
>
>Report an error when something went wrong.
>
>Signed-off-by: Julien Meunier
>Signed-off-by: David Marchand
>---
> drivers/net/enic/enic_ethdev.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/enic/enic_ethdev.c
>b/drivers/net/enic/enic_ethdev.c
>index e385560..5df9a6c 100644
>--- a/drivers/net/enic/enic_ethdev.c
>+++ b/drivers/net/enic/enic_ethdev.c
>@@ -271,13 +271,14 @@ static int enicpmd_vlan_filter_set(struct
>rte_eth_dev *eth_dev,
> uint16_t vlan_id, int on)
> {
> struct enic *enic = pmd_priv(eth_dev);
>+ int err;
>
> ENICPMD_FUNC_TRACE();
> if (on)
>- enic_add_vlan(enic, vlan_id);
>+ err = enic_add_vlan(enic, vlan_id);
> else
>- enic_del_vlan(enic, vlan_id);
>- return 0;
>+ err = enic_del_vlan(enic, vlan_id);
>+ return err;
Acked.
Thanks,
-Sujith
> }
>
> static void enicpmd_vlan_offload_set(struct rte_eth_dev *eth_dev, int
>mask)
>--
>1.9.1
>
[dpdk-dev] [PATCH 2/2] enic: fix hash creation when not using first numa node
On 11/09/15 1:32 pm, "David Marchand" wrote: >If dpdk is run with memory only available on socket != 0, then hash >creation will fail and flow director feature won't be available. >Fix this by asking for allocation on caller socket. > >Signed-off-by: David Marchand >--- > drivers/net/enic/enic_clsf.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > >diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c >index 656b25b..e7416ce 100644 >--- a/drivers/net/enic/enic_clsf.c >+++ b/drivers/net/enic/enic_clsf.c >@@ -61,7 +61,6 @@ > #define DEFAULT_HASH_FUNC rte_jhash > #endif > >-#define SOCKET_00 > #define ENICPMD_CLSF_HASH_ENTRIES ENICPMD_FDIR_MAX > > void enic_fdir_stats_get(struct enic *enic, struct rte_eth_fdir_stats >*stats) >@@ -247,7 +246,7 @@ int enic_clsf_init(struct enic *enic) > .key_len = sizeof(struct rte_eth_fdir_filter), > .hash_func = DEFAULT_HASH_FUNC, > .hash_func_init_val = 0, >- .socket_id = SOCKET_0, >+ .socket_id = SOCKET_ID_ANY, > }; > > enic->fdir.hash = rte_hash_create(_params); >-- Acked by: Sujith Sankar > >1.9.1 >
[dpdk-dev] [PATCH 1/2] enic: fix allocation when not using first numa node
On 11/09/15 1:32 pm, "David Marchand" wrote:
>Seen by code review.
>
>If dpdk is run with memory only available on socket != 0, then enic pmd
>refuses to initialize ports as this pmd requires some memory on socket 0.
>Fix this by setting socket to SOCKET_ID_ANY, so that allocations happen on
>the caller socket.
>
>Signed-off-by: David Marchand
>---
> drivers/net/enic/enic_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
>index 3b8719f..46a90bd 100644
>--- a/drivers/net/enic/enic_main.c
>+++ b/drivers/net/enic/enic_main.c
>@@ -539,7 +539,7 @@ enic_alloc_consistent(__rte_unused void *priv, size_t
>size,
> *dma_handle = 0;
>
> rz = rte_memzone_reserve_aligned((const char *)name,
>- size, 0, 0, ENIC_ALIGN);
>+ size, SOCKET_ID_ANY, 0, ENIC_ALIGN);
> if (!rz) {
> pr_err("%s : Failed to allocate memory requested for %s",
> __func__, name);
>--
Acked by: Sujith Sankar
>
>1.9.1
>
[dpdk-dev] [PATCH 2/3] enic: use appropriate key length in hash table
On 04/09/15 2:35 pm, "Pablo de Lara"
wrote:
>RTE_HASH_KEY_LENGTH_MAX was deprecated, and the hash table
>actually is hosting bigger keys than that size, so key length
>has been increased to properly allocate all keys.
>
>Signed-off-by: Pablo de Lara
>---
> drivers/net/enic/enic_clsf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
>index 9c2abfb..656b25b 100644
>--- a/drivers/net/enic/enic_clsf.c
>+++ b/drivers/net/enic/enic_clsf.c
>@@ -214,7 +214,7 @@ int enic_fdir_add_fltr(struct enic *enic, struct
>rte_eth_fdir_filter *params)
> enic->fdir.stats.add++;
> }
>
>- pos = rte_hash_add_key(enic->fdir.hash, (void *)key);
>+ pos = rte_hash_add_key(enic->fdir.hash, params);
> enic->fdir.nodes[pos] = key;
> return 0;
> }
>@@ -244,7 +244,7 @@ int enic_clsf_init(struct enic *enic)
> struct rte_hash_parameters hash_params = {
> .name = "enicpmd_clsf_hash",
> .entries = ENICPMD_CLSF_HASH_ENTRIES,
>- .key_len = RTE_HASH_KEY_LENGTH_MAX,
>+ .key_len = sizeof(struct rte_eth_fdir_filter),
> .hash_func = DEFAULT_HASH_FUNC,
> .hash_func_init_val = 0,
> .socket_id = SOCKET_0,
>--
Looks good.
Thanks,
-Sujith
>
>2.4.2
>
[dpdk-dev] [PATCH 1/2] enic: silence log message
Stephen, The enic debug flag is off by default. So it is going to print the version only if the user wants it to. Isn?t that fine? Thanks, -Sujith From: Stephen Hemminger <step...@networkplumber.org> Date: Wednesday, 20 May 2015 11:17 pm To: "Sujith Sankar (ssujith)" Cc: Bruce Richardson , "dev at dpdk.org" , Stephen Hemminger Subject: Re: [dpdk-dev] [PATCH 1/2] enic: silence log message Other drivers are quiet, why does this one need to be noisy On Wed, May 20, 2015 at 9:30 AM, Sujith Sankar (ssujith) wrote: On 19/05/15 3:38 pm, "Bruce Richardson" wrote: >On Wed, Apr 08, 2015 at 10:37:49AM -0700, Stephen Hemminger wrote: >> From: Stephen Hemminger >> >> Silence is normal. drivers should speak only when spoken to and not >> be chatty. >> >> Signed-off-by: Stephen Hemminger > >Acked-by: Bruce Richardson > >> --- >> lib/librte_pmd_enic/enic_main.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/lib/librte_pmd_enic/enic_main.c >>b/lib/librte_pmd_enic/enic_main.c >> index 0892b3e..508621e 100644 >> --- a/lib/librte_pmd_enic/enic_main.c >> +++ b/lib/librte_pmd_enic/enic_main.c >> @@ -1048,8 +1048,6 @@ int enic_probe(struct enic *enic) >> struct rte_pci_device *pdev = enic->pdev; >> int err = -1; >> >> -dev_debug(enic, " Initializing ENIC PMD version %s\n", >>DRV_VERSION); >> - It would be good to retain this under RTE_LIBRTE_ENIC_DEBUG. >> enic->bar0.vaddr = (void *)pdev->mem_resource[0].addr; >> enic->bar0.len = pdev->mem_resource[0].len; >> >> -- >> 2.1.4 >>
[dpdk-dev] [PATCH v2 06/19] enic: move enic PMD to drivers/net directory
On 20/05/15 9:44 pm, "Thomas Monjalon" wrote: >2015-05-20 16:04, Richardson, Bruce: >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] >> > 2015-05-15 16:56, Bruce Richardson: >> > > move enic PMD to drivers/net directory >> > > >> > > Signed-off-by: Bruce Richardson >> > > --- >> > > drivers/net/Makefile |2 +- >> > > drivers/net/enic/LICENSE | 27 + >> > > drivers/net/enic/Makefile| 71 ++ >> > > drivers/net/enic/enic.h | 200 + >> > > drivers/net/enic/enic_clsf.c | 259 ++ >> > > drivers/net/enic/enic_compat.h | 147 >> > > drivers/net/enic/enic_ethdev.c | 640 +++ >> > > drivers/net/enic/enic_main.c | 1117 >> > ++ >> > > drivers/net/enic/enic_res.c | 219 + >> > > drivers/net/enic/enic_res.h | 168 >> > > drivers/net/enic/rte_pmd_enic_version.map|4 + >> > > drivers/net/enic/vnic/cq_desc.h | 126 +++ >> > > drivers/net/enic/vnic/cq_enet_desc.h | 261 ++ >> > > drivers/net/enic/vnic/rq_enet_desc.h | 76 ++ >> > > drivers/net/enic/vnic/vnic_cq.c | 117 +++ >> > > drivers/net/enic/vnic/vnic_cq.h | 151 >> > > drivers/net/enic/vnic/vnic_dev.c | 1054 >> > >> > > drivers/net/enic/vnic/vnic_dev.h | 212 + >> > > drivers/net/enic/vnic/vnic_devcmd.h | 774 >>++ >> > > drivers/net/enic/vnic/vnic_enet.h| 78 ++ >> > > drivers/net/enic/vnic/vnic_intr.c| 78 ++ >> > > drivers/net/enic/vnic/vnic_intr.h| 126 +++ >> > > drivers/net/enic/vnic/vnic_nic.h | 88 ++ >> > > drivers/net/enic/vnic/vnic_resource.h| 97 +++ >> > > drivers/net/enic/vnic/vnic_rq.c | 245 ++ >> > > drivers/net/enic/vnic/vnic_rq.h | 282 +++ >> > > drivers/net/enic/vnic/vnic_rss.c | 85 ++ >> > > drivers/net/enic/vnic/vnic_rss.h | 61 ++ >> > > drivers/net/enic/vnic/vnic_stats.h | 86 ++ >> > > drivers/net/enic/vnic/vnic_wq.c | 245 ++ >> > > drivers/net/enic/vnic/vnic_wq.h | 283 +++ >> > > drivers/net/enic/vnic/wq_enet_desc.h | 114 +++ >> > >> > I think that vnic/ should be renamed to base/ >> >> Yes, I was wondering about that. However, this wasn't a driver I was >>familiar with and its origins, so I left it as-is. > >Sujith imported it with this message: >"VNIC common code partially shared with ENIC kernel mode driver" >http://dpdk.org/ml/archives/dev/2014-November/008716.html Please go ahead with the renaming. Is this just for uniformity? Is there any other reason? Thanks, -Sujith >
[dpdk-dev] [PATCH 1/2] enic: silence log message
On 19/05/15 3:38 pm, "Bruce Richardson" wrote: >On Wed, Apr 08, 2015 at 10:37:49AM -0700, Stephen Hemminger wrote: >> From: Stephen Hemminger >> >> Silence is normal. drivers should speak only when spoken to and not >> be chatty. >> >> Signed-off-by: Stephen Hemminger > >Acked-by: Bruce Richardson > >> --- >> lib/librte_pmd_enic/enic_main.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/lib/librte_pmd_enic/enic_main.c >>b/lib/librte_pmd_enic/enic_main.c >> index 0892b3e..508621e 100644 >> --- a/lib/librte_pmd_enic/enic_main.c >> +++ b/lib/librte_pmd_enic/enic_main.c >> @@ -1048,8 +1048,6 @@ int enic_probe(struct enic *enic) >> struct rte_pci_device *pdev = enic->pdev; >> int err = -1; >> >> -dev_debug(enic, " Initializing ENIC PMD version %s\n", DRV_VERSION); >> - It would be good to retain this under RTE_LIBRTE_ENIC_DEBUG. >> enic->bar0.vaddr = (void *)pdev->mem_resource[0].addr; >> enic->bar0.len = pdev->mem_resource[0].len; >> >> -- >> 2.1.4 >>
[dpdk-dev] [PATCH] enicpmd: build changes for FreeBSD
On 06/05/15 9:19 pm, "Bruce Richardson" wrote:
>On Wed, May 06, 2015 at 02:41:00PM +0530, Sujith Sankar wrote:
>> This patch adds the changes required to build enic for FreeBSD
>>
>
>Hi,
>
>I see no issues with this patch, but I suggest the description for it
>should
>be changed. There is no actual build problem or error with the enic (at
>least
>not that I can see), it builds fine with gcc and clang currently. This
>patch
>instead adds support for the enic to the nic_uio driver so the enic can be
>"used", not just "built" on FreeBSD. Correct?
Bruce, I fully agree with you.
I shall change the description and re-submit the patch.
Thanks !
-Sujith
>
>Other than that description reworking:
>
>Acked-by: Bruce Richardson
>
>> Signed-off-by: Sujith Sankar
>> ---
>> lib/librte_eal/bsdapp/nic_uio/nic_uio.c | 1 +
>> lib/librte_eal/common/include/rte_pci_dev_ids.h | 17 +
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
>>b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
>> index 5ae8560..e649e32 100644
>> --- a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
>> +++ b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
>> @@ -113,6 +113,7 @@ struct pci_bdf {
>> #define RTE_PCI_DEV_ID_DECL_I40EVF(vend, dev) {vend, dev},
>> #define RTE_PCI_DEV_ID_DECL_VIRTIO(vend, dev) {vend, dev},
>> #define RTE_PCI_DEV_ID_DECL_VMXNET3(vend, dev) {vend, dev},
>> +#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev){vend, dev},
>>
>> const struct device devices[] = {
>> #include
>> diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
>>b/lib/librte_eal/common/include/rte_pci_dev_ids.h
>> index 21d2eed..5d1b285 100644
>> --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
>> +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
>> @@ -140,6 +140,10 @@
>> #define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev)
>> #endif
>>
>> +#ifndef RTE_PCI_DEV_ID_DECL_ENIC
>> +#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
>> +#endif
>> +
>> #ifndef PCI_VENDOR_ID_INTEL
>> /** Vendor ID used by Intel devices */
>> #define PCI_VENDOR_ID_INTEL 0x8086
>> @@ -155,6 +159,11 @@
>> #define PCI_VENDOR_ID_VMWARE 0x15AD
>> #endif
>>
>> +#ifndef PCI_VENDOR_ID_CISCO
>> +/** Vendor ID used by Cisco VIC devices */
>> +#define PCI_VENDOR_ID_CISCO 0x1137
>> +#endif
>> +
>> / Physical EM devices from e1000_hw.h
>>/
>>
>> #define E1000_DEV_ID_825420x1000
>> @@ -548,6 +557,14 @@ RTE_PCI_DEV_ID_DECL_VMXNET3(PCI_VENDOR_ID_VMWARE,
>>VMWARE_DEV_ID_VMXNET3)
>>
>> RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, FM10K_DEV_ID_VF)
>>
>> +/** Cisco VIC devices **/
>> +
>> +#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic
>>*/
>> +#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF 0x0071 /* enet SRIOV VF
>>*/
>> +
>> +RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>>PCI_DEVICE_ID_CISCO_VIC_ENET)
>> +RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>>PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
>> +
>> /*
>> * Undef all RTE_PCI_DEV_ID_DECL_* here.
>> */
>> --
>> 1.9.1
>>
[dpdk-dev] [PATCH] enic: disable debug traces
On 07/04/15 11:10 pm, "Thomas Monjalon" wrote:
>The function name is printed in each enic_ethdev function.
>Disable it by default with a new build option.
>
>Signed-off-by: Thomas Monjalon
>---
> config/common_bsdapp | 1 +
> config/common_linuxapp| 1 +
> lib/librte_pmd_enic/enic_ethdev.c | 4
> 3 files changed, 6 insertions(+)
>
>diff --git a/config/common_bsdapp b/config/common_bsdapp
>index a8ba484..c2374c0 100644
>--- a/config/common_bsdapp
>+++ b/config/common_bsdapp
>@@ -214,6 +214,7 @@ CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> # Compile burst-oriented Cisco ENIC PMD driver
> #
> CONFIG_RTE_LIBRTE_ENIC_PMD=y
>+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>
> #
> # Compile burst-oriented VIRTIO PMD driver
>diff --git a/config/common_linuxapp b/config/common_linuxapp
>index 0b25f34..0078dc9 100644
>--- a/config/common_linuxapp
>+++ b/config/common_linuxapp
>@@ -211,6 +211,7 @@ CONFIG_RTE_LIBRTE_MLX4_SOFT_COUNTERS=1
> # Compile burst-oriented Cisco ENIC PMD driver
> #
> CONFIG_RTE_LIBRTE_ENIC_PMD=y
>+CONFIG_RTE_LIBRTE_ENIC_DEBUG=n
>
> #
> # Compile burst-oriented VIRTIO PMD driver
>diff --git a/lib/librte_pmd_enic/enic_ethdev.c
>b/lib/librte_pmd_enic/enic_ethdev.c
>index 4950ede..18fadfb 100644
>--- a/lib/librte_pmd_enic/enic_ethdev.c
>+++ b/lib/librte_pmd_enic/enic_ethdev.c
>@@ -48,8 +48,12 @@
> #include "vnic_enet.h"
> #include "enic.h"
>
>+#ifdef RTE_LIBRTE_ENIC_DEBUG
> #define ENICPMD_FUNC_TRACE() \
> RTE_LOG(DEBUG, PMD, "ENICPMD trace: %s\n", __func__)
>+#else
>+#define ENICPMD_FUNC_TRACE() do {} while (0)
>+#endif
>
> /*
> * The set of PCI devices this driver supports
>--
>2.2.2
>
Acked-by: Sujith Sankar
>
[dpdk-dev] [PATCH v6 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD
On 27/02/15 4:16 pm, "Thomas Monjalon" wrote: >2015-02-27 08:09, Sujith Sankar: >> Hi Thomas, >> >> No update on it from my side :-( >> It would take some more time for me to start working on it (and flow >> director api) as a few other things are keeping me busy. > >It's unfortunate. >We now have a PMD without documentation and blocking the removal of the >old flow director API. >Is there someone else at Cisco able to work on it? >I think the first priority should be on the flow director API as it has a >wider impact. Sure Thomas. I shall pick it up as soon as possible. Thanks. > >Thanks
[dpdk-dev] [PATCH] enic: silence log message
Stephen, Saw your patch. Will take a look. Thanks, -Sujith On 15/02/15 11:43 am, "Sujith Sankar (ssujith)" wrote: >Hi Stephen, David, > >I agree with you and shall submit this change. > >Thanks, >-Sujith > >On 09/02/15 9:41 pm, "Stephen Hemminger" >wrote: > >>Agree it should not use printf. >>If you insist on keeping the useless message then it should be log level >>debug >
[dpdk-dev] [PATCH] enic: silence log message
Hi Stephen, David, I agree with you and shall submit this change. Thanks, -Sujith On 09/02/15 9:41 pm, "Stephen Hemminger" wrote: >Agree it should not use printf. >If you insist on keeping the useless message then it should be log level >debug
[dpdk-dev] [PATCH v6 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD
Hi David, Apologies for the delay. I was not able to find quality time to finish it as a few other things have been keeping me busy. But I shall work on it and provide the doc and the perf details soon. In the mean time, it would be great if you could point me to some resources on running pktgen-dpdk as I was stuck on it. Thanks, -Sujith From: David Marchand mailto:david.march...@6wind.com>> Date: Tuesday, 20 January 2015 4:55 pm To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>> Cc: "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>>, "Prasad Rao (prrao)" mailto:prrao at cisco.com>>, Neil Horman mailto:nhorman at tuxdriver.com>>, Thomas Monjalon mailto:thomas.monjalon at 6wind.com>> Subject: Re: [dpdk-dev] [PATCH v6 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD Hello Sujith, Any news on the documentation and the performance numbers you said you would send ? Thanks. -- David Marchand On Thu, Nov 27, 2014 at 4:31 PM, Thomas Monjalon mailto:thomas.monjalon at 6wind.com>> wrote: 2014-11-27 04:27, Sujith Sankar: > Thanks Thomas, David and Neil ! > > I shall work on finishing the documentation. > About that, you had mentioned that you wanted it in doc/drivers/ path. > Could I send a patch with documentation in the path doc/drivers/enicpmd/ ? Yes. I'd prefer doc/drivers/enic/ but it's a detail ;) The format must be sphinx rst to allow web publishing. It would be great to have some design documentation of every drivers in doc/drivers. Thanks -- Thomas
[dpdk-dev] [PATCH v6 5/6] enicpmd: DPDK-ENIC PMD interface
On 29/12/14 1:45 pm, "Wu, Jingjing" wrote:
>Hi, ssujith
>
>> +.tx_queue_release = enicpmd_dev_tx_queue_release,
>> +.dev_led_on = NULL,
>> +.dev_led_off = NULL,
>> +.flow_ctrl_get= NULL,
>> +.flow_ctrl_set= NULL,
>> +.priority_flow_ctrl_set = NULL,
>> +.mac_addr_add = enicpmd_add_mac_addr,
>> +.mac_addr_remove = enicpmd_remove_mac_addr,
>> +.fdir_add_signature_filter= NULL,
>> +.fdir_update_signature_filter = NULL,
>> +.fdir_remove_signature_filter = NULL,
>> +.fdir_infos_get = enicpmd_fdir_info_get,
>> +.fdir_add_perfect_filter = enicpmd_fdir_add_perfect_filter,
>> +.fdir_update_perfect_filter = enicpmd_fdir_add_perfect_filter,
>> +.fdir_remove_perfect_filter = enicpmd_fdir_remove_perfect_filter,
>> +.fdir_set_masks = NULL,
>> +};
>> +
>
>I found that in perfect fdir is also supported in enic driver.
>
>During the R1.8 development, we defined a new dev_ops call filter_ctrl,
>which can be used to control kinds of filters, flow director is included
>too. Which is mentioned in
>http://www.dpdk.org/ml/archives/dev/2014-September/005179.html .
>In R1.8, filter_ctrl is only used by i40e driver. And we also planned use
>it in the existing ixgbe/e1000 driver in the next days. The old APIs such
>as fdir_add_perfect_filter, fdir_remove_perfect_filter can be replaced
>then.
Hi Jingjing,
Thanks for the info and the link. I shall take a look at it.
It looks like bringing in one interface for all filter related operations.
I believe ENIC should also move to it.
Thanks,
-Sujith
>
>So, do you have any plan to migrate the fdir in enic to the filter_ctrl
>API?
>
>Jingjing
>
>Thanks!
>
>> +struct enic *enicpmd_list_head = NULL;
>> +/* Initialize the driver
>> + * It returns 0 on success.
>> + */
>> +static int eth_enicpmd_dev_init(
>> +__attribute__((unused))struct eth_driver *eth_drv,
>> +struct rte_eth_dev *eth_dev)
>> +{
>> +struct rte_pci_device *pdev;
>> +struct rte_pci_addr *addr;
>> +struct enic *enic = pmd_priv(eth_dev);
>> +
>> +ENICPMD_FUNC_TRACE();
>> +
>> +enic->rte_dev = eth_dev;
>> +eth_dev->dev_ops = _eth_dev_ops;
>> +eth_dev->rx_pkt_burst = _recv_pkts;
>> +eth_dev->tx_pkt_burst = _xmit_pkts;
>> +
>> +pdev = eth_dev->pci_dev;
>> +enic->pdev = pdev;
>> +addr = >addr;
>> +
>> +snprintf(enic->bdf_name, ENICPMD_BDF_LENGTH,
>> "%04x:%02x:%02x.%x",
>> +addr->domain, addr->bus, addr->devid, addr->function);
>> +
>> +return enic_probe(enic);
>> +}
>> +
>> +static struct eth_driver rte_enic_pmd = {
>> +{
>> +.name = "rte_enic_pmd",
>> +.id_table = pci_id_enic_map,
>> +.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
>> +},
>> +.eth_dev_init = eth_enicpmd_dev_init,
>> +.dev_private_size = sizeof(struct enic), };
>> +
>> +/* Driver initialization routine.
>> + * Invoked once at EAL init time.
>> + * Register as the [Poll Mode] Driver of Cisco ENIC device.
>> + */
>> +int rte_enic_pmd_init(const char *name __rte_unused,
>> +const char *params __rte_unused)
>> +{
>> +ENICPMD_FUNC_TRACE();
>> +
>> +rte_eth_driver_register(_enic_pmd);
>> +return 0;
>> +}
>> +
>> +static struct rte_driver rte_enic_driver = {
>> +.type = PMD_PDEV,
>> +.init = rte_enic_pmd_init,
>> +};
>> +
>> +PMD_REGISTER_DRIVER(rte_enic_driver);
>> +
>> --
>> 1.9.1
>
[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT
On 16/12/14 4:06 pm, "Burakov, Anatoly" wrote: >> -Original Message- >> From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com] >> Sent: Tuesday, December 16, 2014 10:34 AM >> To: Burakov, Anatoly; Thomas Monjalon >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] enic: corrected the usage of >>VFIO_PRESENT >> >> >> >> On 16/12/14 3:52 pm, "Burakov, Anatoly" >> wrote: >> >> >> On 16/12/14 4:54 am, "Thomas Monjalon" >> >> >> wrote: >> >> >> >> >2014-12-12 13:48, Sujith Sankar: >> >> >> This patch corrects the usage of the flag VFIO_PRESENT in enic >> >>driver. >> >> > >> >> >Please, could you explain why the flag VFIO_PRESENT was not well >> used? >> >> >> >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic. >> >> Hence VFIO specific code in enic was not getting compiled and some >> >>errors were generated during run-time. >> >> >> >> > >> >> >> This has uncovered a few warnings, and this patch corrects those >>too. >> >> >[...] >> >> >> --- a/lib/librte_pmd_enic/enic_main.c >> >> >> +++ b/lib/librte_pmd_enic/enic_main.c >> >> >> @@ -39,6 +39,7 @@ >> >> >> #include >> >> >> #include >> >> >> #include >> >> >> +#include >> >> >> >> >> >> #include >> >> >> #include >> >> >> @@ -46,6 +47,7 @@ >> >> >> #include >> >> >> #include >> >> >> #include >> >> >> +#include >> >> > >> >> >This header was not designed to be included by PMDs. >> >> >It will break compilation on BSD. >> >> >> >> Is there an alternative to make VFIO_PRESENT available in enic? >> >> Please advise. >> >> >> >> Thanks, >> >> -Sujith >> >> >> >> > >> >> >> #include "enic_compat.h" >> >> >> #include "enic.h" >> >> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct >> >> >>rte_pci_device *hwdev, >> >> >>/* Nothing to be done */ >> >> >> } >> >> >> >> >> >> +#ifndef VFIO_PRESENT >> >> >> static void >> >> >> enic_intr_handler(__rte_unused struct rte_intr_handle *handle, >> >> >>void *arg) >> >> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct >> >> >>rte_intr_handle *handle, >> >> >> >> >> >>enic_log_q_error(enic); >> >> >> } >> >> >> +#endif >> >> > >> >> >-- >> >> >Thomas >> > >> >Hi Sujith >> > >> >Thomas is correct, VFIO code is designed to be EAL-only (mainly because >> >it's Linuxapp-specific, and PMD's are intended to be cross-platform at >> >least when it comes to compilation). Whatever it is that you're working >> >around is better fixed in the EAL itself rather than in the PMD. >> >> I agree with you and Thomas. Let me find the root cause for the false >>trigger. >> >> Thanks, >> -Sujith >> > >You may find it in EAL VFIO interrupts code. When VFIO enables some >interrupt types, it manually sends a trigger. Normally, this "trigger" >just enables interrupts, but maybe for ENIC it's different. I therefore >suggest you to look there first. Ok. Thanks for the info, Anatoly. ENIC does not need that trigger. Let me take a look at that first. Thanks, -Sujith > >Thanks, >Anatoly
[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT
On 16/12/14 3:52 pm, "Burakov, Anatoly" wrote: >> On 16/12/14 4:54 am, "Thomas Monjalon" >> wrote: >> >> >2014-12-12 13:48, Sujith Sankar: >> >> This patch corrects the usage of the flag VFIO_PRESENT in enic >>driver. >> > >> >Please, could you explain why the flag VFIO_PRESENT was not well used? >> >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic. >> Hence VFIO specific code in enic was not getting compiled and some >>errors >> were generated during run-time. >> >> > >> >> This has uncovered a few warnings, and this patch corrects those too. >> >[...] >> >> --- a/lib/librte_pmd_enic/enic_main.c >> >> +++ b/lib/librte_pmd_enic/enic_main.c >> >> @@ -39,6 +39,7 @@ >> >> #include >> >> #include >> >> #include >> >> +#include >> >> >> >> #include >> >> #include >> >> @@ -46,6 +47,7 @@ >> >> #include >> >> #include >> >> #include >> >> +#include >> > >> >This header was not designed to be included by PMDs. >> >It will break compilation on BSD. >> >> Is there an alternative to make VFIO_PRESENT available in enic? Please >> advise. >> >> Thanks, >> -Sujith >> >> > >> >> #include "enic_compat.h" >> >> #include "enic.h" >> >> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct >> >>rte_pci_device *hwdev, >> >> /* Nothing to be done */ >> >> } >> >> >> >> +#ifndef VFIO_PRESENT >> >> static void >> >> enic_intr_handler(__rte_unused struct rte_intr_handle *handle, >> >> void *arg) >> >> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct >> >>rte_intr_handle *handle, >> >> >> >> enic_log_q_error(enic); >> >> } >> >> +#endif >> > >> >-- >> >Thomas > >Hi Sujith > >Thomas is correct, VFIO code is designed to be EAL-only (mainly because >it's Linuxapp-specific, and PMD's are intended to be cross-platform at >least when it comes to compilation). Whatever it is that you're working >around is better fixed in the EAL itself rather than in the PMD. I agree with you and Thomas. Let me find the root cause for the false trigger. Thanks, -Sujith > >Thanks, >Anatoly
[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT
On 16/12/14 1:21 pm, "Qiu, Michael" wrote: >On 12/16/2014 12:13 PM, Sujith Sankar (ssujith) wrote: >> On 16/12/14 4:54 am, "Thomas Monjalon" >>wrote: >> >>> 2014-12-12 13:48, Sujith Sankar: >>>> This patch corrects the usage of the flag VFIO_PRESENT in enic driver. >>> Please, could you explain why the flag VFIO_PRESENT was not well used? >> Without including eal_vfio.h, VFIO_PRESENT is not available in enic. >> Hence VFIO specific code in enic was not getting compiled and some >>errors >> were generated during run-time. >> >>>> This has uncovered a few warnings, and this patch corrects those too. >>> [...] >>>> --- a/lib/librte_pmd_enic/enic_main.c >>>> +++ b/lib/librte_pmd_enic/enic_main.c >>>> @@ -39,6 +39,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #include >>>> #include >>>> @@ -46,6 +47,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>> This header was not designed to be included by PMDs. >>> It will break compilation on BSD. >> Is there an alternative to make VFIO_PRESENT available in enic? Please >> advise. > >You can remove VFIO_PRESENT check, it all been done in eal, you can >check other nic pmds for reference. >And seems you done the interrupt logic all by your self? > >Thanks, >Michael Thanks for the comment, Michael. Without the code under VFIO_PRESENT flag, I was getting false notification of interrupt at the beginning (cat /proc/interrupts showed all 0s). Let me try to root cause it. I shall get back after some debugging and testing. There was one more reason behind doing interrupt logic in enic. No matter how many interrupts the user configures, enic pmd needs only one. There is no way to communicate that to the EAL. I thought doing interrupt login in enic could avoid registering that many interrupts. Thanks, -Sujith >> >> Thanks, >> -Sujith >> >>>> #include "enic_compat.h" >>>> #include "enic.h" >>>> @@ -561,6 +563,7 @@ enic_free_consistent(__rte_unused struct >>>> rte_pci_device *hwdev, >>>>/* Nothing to be done */ >>>> } >>>> >>>> +#ifndef VFIO_PRESENT >>>> static void >>>> enic_intr_handler(__rte_unused struct rte_intr_handle *handle, >>>>void *arg) >>>> @@ -572,6 +575,7 @@ enic_intr_handler(__rte_unused struct >>>> rte_intr_handle *handle, >>>> >>>>enic_log_q_error(enic); >>>> } >>>> +#endif >>> -- >>> Thomas >> >
[dpdk-dev] [PATCH] enic: fix warnings
On 02/12/14 8:29 pm, "Thomas Monjalon" wrote:
>A lot of warnings were not seen because $(WERROR_FLAGS) was not set
>in the Makefile. But they appear with toolchains that enforce more checks.
>
>-Wno-deprecated seems useless.
>-Wno-strict-aliasing is added to avoid false positives.
>
>This patch cleans up unused variable, unused functions, wrong types,
>static declarations, etc. A lot of functions have unused parameters;
>it suggests that more clean-up could be needed.
>
>Signed-off-by: Thomas Monjalon
>---
> lib/librte_pmd_enic/Makefile | 3 +-
> lib/librte_pmd_enic/enic.h | 4 +-
> lib/librte_pmd_enic/enic_ethdev.c| 20 -
Thomas, the name of this file got modified. It was enic_etherdev.c in my
submission.
Any idea how this happened? I do not remember seeing a request for this.
Thanks,
-Sujith
> lib/librte_pmd_enic/enic_main.c | 81
>+++-
> lib/librte_pmd_enic/vnic/vnic_cq.h | 1 -
> lib/librte_pmd_enic/vnic/vnic_dev.c | 22 +++---
> lib/librte_pmd_enic/vnic/vnic_dev.h | 4 +-
> lib/librte_pmd_enic/vnic/vnic_intr.c | 5 ---
> 8 files changed, 46 insertions(+), 94 deletions(-)
>
>diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
>index 948ec96..a2a623f 100644
>--- a/lib/librte_pmd_enic/Makefile
>+++ b/lib/librte_pmd_enic/Makefile
>@@ -39,7 +39,8 @@ LIB = librte_pmd_enic.a
>
> CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/vnic/
> CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/
>-CFLAGS += -O3 -Wno-deprecated
>+CFLAGS += -O3
>+CFLAGS += $(WERROR_FLAGS) -Wno-strict-aliasing
>
> VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
>
>diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
>index f128e64..c43417c 100644
>--- a/lib/librte_pmd_enic/enic.h
>+++ b/lib/librte_pmd_enic/enic.h
>@@ -134,7 +134,7 @@ struct enic {
> unsigned int intr_count;
> };
>
>-static inline unsigned int enic_cq_rq(struct enic *enic, unsigned int rq)
>+static inline unsigned int enic_cq_rq(__rte_unused struct enic *enic,
>unsigned int rq)
> {
> return rq;
> }
>@@ -144,7 +144,7 @@ static inline unsigned int enic_cq_wq(struct enic
>*enic, unsigned int wq)
> return enic->rq_count + wq;
> }
>
>-static inline unsigned int enic_msix_err_intr(struct enic *enic)
>+static inline unsigned int enic_msix_err_intr(__rte_unused struct enic
>*enic)
> {
> return 0;
> }
>diff --git a/lib/librte_pmd_enic/enic_ethdev.c
>b/lib/librte_pmd_enic/enic_ethdev.c
>index f582152..9cb 100644
>--- a/lib/librte_pmd_enic/enic_ethdev.c
>+++ b/lib/librte_pmd_enic/enic_ethdev.c
>@@ -67,7 +67,7 @@ RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
>
> static int enicpmd_fdir_remove_perfect_filter(struct rte_eth_dev
>*eth_dev,
> struct rte_fdir_filter *fdir_filter,
>- uint16_t soft_id)
>+ __rte_unused uint16_t soft_id)
> {
> struct enic *enic = pmd_priv(eth_dev);
>
>@@ -76,7 +76,7 @@ static int enicpmd_fdir_remove_perfect_filter(struct
>rte_eth_dev *eth_dev,
> }
>
> static int enicpmd_fdir_add_perfect_filter(struct rte_eth_dev *eth_dev,
>- struct rte_fdir_filter *fdir_filter, uint16_t soft_id,
>+ struct rte_fdir_filter *fdir_filter, __rte_unused uint16_t soft_id,
> uint8_t queue, uint8_t drop)
> {
> struct enic *enic = pmd_priv(eth_dev);
>@@ -103,7 +103,7 @@ static void enicpmd_dev_tx_queue_release(void *txq)
> static int enicpmd_dev_setup_intr(struct enic *enic)
> {
> int ret;
>- int index;
>+ unsigned int index;
>
> ENICPMD_FUNC_TRACE();
>
>@@ -134,7 +134,7 @@ static int enicpmd_dev_tx_queue_setup(struct
>rte_eth_dev *eth_dev,
> uint16_t queue_idx,
> uint16_t nb_desc,
> unsigned int socket_id,
>- const struct rte_eth_txconf *tx_conf)
>+ __rte_unused const struct rte_eth_txconf *tx_conf)
> {
> int ret;
> struct enic *enic = pmd_priv(eth_dev);
>@@ -215,7 +215,7 @@ static int enicpmd_dev_rx_queue_setup(struct
>rte_eth_dev *eth_dev,
> uint16_t queue_idx,
> uint16_t nb_desc,
> unsigned int socket_id,
>- const struct rte_eth_rxconf *rx_conf,
>+ __rte_unused const struct rte_eth_rxconf *rx_conf,
> struct rte_mempool *mp)
> {
> int ret;
>@@ -334,7 +334,7 @@ static void enicpmd_dev_close(struct rte_eth_dev
>*eth_dev)
> }
>
> static int enicpmd_dev_link_update(struct rte_eth_dev *eth_dev,
>- int wait_to_complete)
>+ __rte_unused int wait_to_complete)
> {
> struct enic *enic = pmd_priv(eth_dev);
> int ret;
>@@ -428,7 +428,7 @@ static void enicpmd_dev_allmulticast_disable(struct
>rte_eth_dev *eth_dev)
>
> static void enicpmd_add_mac_addr(struct rte_eth_dev *eth_dev,
> struct ether_addr *mac_addr,
>- uint32_t index, uint32_t pool)
>+ __rte_unused uint32_t index, __rte_unused uint32_t pool)
> {
> struct enic *enic = pmd_priv(eth_dev);
>
>@@ -436,7 +436,7 @@ static void enicpmd_add_mac_addr(struct
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
On 01/12/14 4:27 pm, "Bruce Richardson" wrote:
>On Sat, Nov 29, 2014 at 12:47:37PM +0530, Sujith Sankar wrote:
>> This patch fixes the warnings and error reported by clang compiler on
>>Linux.
>>
>> Reported-by: Bruce Richardson
>> Signed-off-by: Sujith Sankar
>
>This PMD now compiles up with clang on FreeBSD. The patch seems rather
>large though,
>are all these changes necessary for clang compilation?
Yes. This patch has only the changes to fix compilation on clang, and it
modifies enic code only.
>
>On the basis that this fixes the issue though:
>
>Acked-by: Bruce Richardson
Thanks Bruce.
>
>> ---
>> lib/librte_pmd_enic/enic.h | 40
>>+
>> lib/librte_pmd_enic/enic_compat.h | 1 +
>> lib/librte_pmd_enic/enic_main.c | 31 +++-
>> lib/librte_pmd_enic/vnic/vnic_dev.c | 19 ++
>> lib/librte_pmd_enic/vnic/vnic_dev.h | 9 +
>> 5 files changed, 78 insertions(+), 22 deletions(-)
>>
>> diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
>> index 6400d24..f128e64 100644
>> --- a/lib/librte_pmd_enic/enic.h
>> +++ b/lib/librte_pmd_enic/enic.h
>> @@ -154,4 +154,44 @@ static inline struct enic *pmd_priv(struct
>>rte_eth_dev *eth_dev)
>> return (struct enic *)eth_dev->data->dev_private;
>> }
>>
>> +extern int enic_fdir_add_fltr(struct enic *enic,
>> +struct rte_fdir_filter *params, u16 queue, u8 drop);
>> +extern int enic_fdir_del_fltr(struct enic *enic,
>> +struct rte_fdir_filter *params);
>> +extern void enic_free_wq(void *txq);
>> +extern int enic_alloc_intr_resources(struct enic *enic);
>> +extern int enic_setup_finish(struct enic *enic);
>> +extern int enic_alloc_wq(struct enic *enic, uint16_t queue_idx,
>> +unsigned int socket_id, uint16_t nb_desc);
>> +extern void enic_start_wq(struct enic *enic, uint16_t queue_idx);
>> +extern int enic_stop_wq(struct enic *enic, uint16_t queue_idx);
>> +extern void enic_start_rq(struct enic *enic, uint16_t queue_idx);
>> +extern int enic_stop_rq(struct enic *enic, uint16_t queue_idx);
>> +extern void enic_free_rq(void *rxq);
>> +extern int enic_alloc_rq(struct enic *enic, uint16_t queue_idx,
>> +unsigned int socket_id, struct rte_mempool *mp,
>> +uint16_t nb_desc);
>> +extern int enic_set_rss_nic_cfg(struct enic *enic);
>> +extern int enic_set_vnic_res(struct enic *enic);
>> +extern void enic_set_hdr_split_size(struct enic *enic, u16
>>split_hdr_size);
>> +extern int enic_enable(struct enic *enic);
>> +extern int enic_disable(struct enic *enic);
>> +extern void enic_remove(struct enic *enic);
>> +extern int enic_get_link_status(struct enic *enic);
>> +extern void enic_dev_stats_get(struct enic *enic,
>> +struct rte_eth_stats *r_stats);
>> +extern void enic_dev_stats_clear(struct enic *enic);
>> +extern void enic_add_packet_filter(struct enic *enic);
>> +extern void enic_set_mac_address(struct enic *enic, uint8_t *mac_addr);
>> +extern void enic_del_mac_address(struct enic *enic);
>> +extern unsigned int enic_cleanup_wq(struct enic *enic, struct vnic_wq
>>*wq);
>> +extern int enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
>> +struct rte_mbuf *tx_pkt, unsigned short len,
>> +uint8_t sop, uint8_t eop,
>> +uint16_t ol_flags, uint16_t vlan_tag);
>> +extern int enic_poll(struct vnic_rq *rq, struct rte_mbuf **rx_pkts,
>> +unsigned int budget, unsigned int *work_done);
>> +extern int enic_probe(struct enic *enic);
>> +extern int enic_clsf_init(struct enic *enic);
>> +extern void enic_clsf_destroy(struct enic *enic);
>> #endif /* _ENIC_H_ */
>> diff --git a/lib/librte_pmd_enic/enic_compat.h
>>b/lib/librte_pmd_enic/enic_compat.h
>> index b3738ee..b1af838 100644
>> --- a/lib/librte_pmd_enic/enic_compat.h
>> +++ b/lib/librte_pmd_enic/enic_compat.h
>> @@ -37,6 +37,7 @@
>> #define _ENIC_COMPAT_H_
>>
>> #include
>> +#include
>>
>> #include
>> #include
>> diff --git a/lib/librte_pmd_enic/enic_main.c
>>b/lib/librte_pmd_enic/enic_main.c
>> index 853dd04..4bbf1e4 100644
>> --- a/lib/librte_pmd_enic/enic_main.c
>> +++ b/lib/librte_pmd_enic/enic_main.c
>> @@ -65,17 +65,17 @@ static inline int enic_is_sriov_vf(struct enic
>>*enic)
>> return enic->pdev->id.device_id == PCI_DEVICE_ID_CISCO_VIC_ENET_VF;
>> }
>>
>> -static int is_zero_addr(char *addr)
>> +static int is_zero_addr(uint8_t *addr)
>> {
>> return !(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]);
>> }
>>
>> -static int is_mcast_addr(char *addr)
>> +static int is_mcast_addr(uint8_t *addr)
>> {
>> return addr[0] & 1;
>> }
>>
>> -static int is_eth_addr_valid(char *addr)
>> +static int is_eth_addr_valid(uint8_t *addr)
>> {
>> return !is_mcast_addr(addr) && !is_zero_addr(addr);
>> }
>> @@ -105,7 +105,8 @@ static const struct rte_memzone
>>*ring_dma_zone_reserve(
>> if (mz)
>> return mz;
>>
>> -return rte_memzone_reserve_aligned(z_name, (uint64_t) ring_size,
>> +return
[dpdk-dev] [PATCH] enicpd: Warnings and one error when built using clang compiler
On 29/11/14 4:47 pm, "Thomas Monjalon" wrote: >29/11/2014 07:22, Sujith Sankar : >> Sorry for the typo in the subject. It is enicpmd. > >Actually no, it should be enic. Usually we use enic to denote the kernel mode driver and enicpmd to denote the PMD. But it is alright to follow what?s being done in the community. I shall use enic from now on. >For virtio, it is not virtiopmd, for ixgbe, it is not ixgbepmd, etc :) >Talking about title, please start with lower case and a verb, e.g. fix >build >with clang. >To have a good idea of title formatting, you could check at the git >history. Sure. I shall follow these. Thanks, -Sujith > >Thanks >-- >Thomas
[dpdk-dev] [PATCH v2] enicpmd: replace the type u_int* with uint* to remove compilation errors on a few platforms
On 28/11/14 9:36 pm, "Bruce Richardson" wrote: >On Fri, Nov 28, 2014 at 04:01:00PM +, Sujith Sankar (ssujith) wrote: >> >> >> On 28/11/14 9:22 pm, "Bruce Richardson" >>wrote: >> >> >On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote: >> >> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc >> >>because >> >> of types such as u_int32_t. This patch replaces all those with >> >>uint32_t and >> >> similar ones. >> >> >> >> Reported-by: David Marchand >> >> Signed-off-by: Sujith Sankar >> > >> >Acked-by: Bruce Richardson >> > >> >This patch helps out with getting a clang compile on BSD. However, one >> >error >> >and a number of warnings remain that should be looked at in another >>patch. >> >The error is: >> > >> >dpdk.org/lib/librte_pmd_enic/enic_main.c:435:3: fatal error: non-void >> >function 'enic_rq_indicate_buf' should return a value [-Wreturn-type] >> >return; >> >> Bruce, thanks for the comment. I?ve not built enicpmd using clang >> compiler. >> I shall setup a BSD build with clang compiler and send a patch with >> necessary fixes. >> Could you please let me know the versions and flavours that you are >>using? >> >> Thanks, >> -Sujith >> >Clang on a linux install gives the same errors, as far as I can see. What >I'm using is clang 3.4 on Fedora 20, and clang 3.3 on FreeBSD 10. > >If you like, if you just fix clang on Linux compilation, I can check for >any >additional errors on FreeBSD and get back to you on them, rather than you >having >to install a FreeBSD system right away. Thank you Bruce. I shall start with Clang on Linux and send the patch soon. > >/Bruce
[dpdk-dev] [PATCH v2] enicpmd: replace the type u_int* with uint* to remove compilation errors on a few platforms
On 28/11/14 9:22 pm, "Bruce Richardson" wrote:
>On Fri, Nov 28, 2014 at 03:08:19PM +0530, Sujith Sankar wrote:
>> ENIC PMD was giving compilation errors on ppc_64-power8-linuxapp-gcc
>>because
>> of types such as u_int32_t. This patch replaces all those with
>>uint32_t and
>> similar ones.
>>
>> Reported-by: David Marchand
>> Signed-off-by: Sujith Sankar
>
>Acked-by: Bruce Richardson
>
>This patch helps out with getting a clang compile on BSD. However, one
>error
>and a number of warnings remain that should be looked at in another patch.
>The error is:
>
>dpdk.org/lib/librte_pmd_enic/enic_main.c:435:3: fatal error: non-void
>function 'enic_rq_indicate_buf' should return a value [-Wreturn-type]
>return;
Bruce, thanks for the comment. I?ve not built enicpmd using clang
compiler.
I shall setup a BSD build with clang compiler and send a patch with
necessary fixes.
Could you please let me know the versions and flavours that you are using?
Thanks,
-Sujith
>
>> ---
>> lib/librte_pmd_enic/enic.h | 2 +-
>> lib/librte_pmd_enic/enic_compat.h | 24
>> lib/librte_pmd_enic/enic_main.c| 18 +-
>> lib/librte_pmd_enic/vnic/vnic_devcmd.h | 6 +++---
>> 4 files changed, 25 insertions(+), 25 deletions(-)
>>
>> diff --git a/lib/librte_pmd_enic/enic.h b/lib/librte_pmd_enic/enic.h
>> index 9f80fc0..6400d24 100644
>> --- a/lib/librte_pmd_enic/enic.h
>> +++ b/lib/librte_pmd_enic/enic.h
>> @@ -106,7 +106,7 @@ struct enic {
>> int iommu_group_fd;
>> int iommu_groupid;
>> int eventfd;
>> -u_int8_t mac_addr[ETH_ALEN];
>> +uint8_t mac_addr[ETH_ALEN];
>> pthread_t err_intr_thread;
>> int promisc;
>> int allmulti;
>> diff --git a/lib/librte_pmd_enic/enic_compat.h
>>b/lib/librte_pmd_enic/enic_compat.h
>> index d22578e..b3738ee 100644
>> --- a/lib/librte_pmd_enic/enic_compat.h
>> +++ b/lib/librte_pmd_enic/enic_compat.h
>> @@ -89,34 +89,34 @@ typedef unsigned intu32;
>> typedef unsigned long long u64;
>> typedef unsigned long long dma_addr_t;
>>
>> -static inline u_int32_t ioread32(volatile void *addr)
>> +static inline uint32_t ioread32(volatile void *addr)
>> {
>> -return *(volatile u_int32_t *)addr;
>> +return *(volatile uint32_t *)addr;
>> }
>>
>> -static inline u16 ioread16(volatile void *addr)
>> +static inline uint16_t ioread16(volatile void *addr)
>> {
>> -return *(volatile u16 *)addr;
>> +return *(volatile uint16_t *)addr;
>> }
>>
>> -static inline u_int8_t ioread8(volatile void *addr)
>> +static inline uint8_t ioread8(volatile void *addr)
>> {
>> -return *(volatile u_int8_t *)addr;
>> +return *(volatile uint8_t *)addr;
>> }
>>
>> -static inline void iowrite32(u_int32_t val, volatile void *addr)
>> +static inline void iowrite32(uint32_t val, volatile void *addr)
>> {
>> -*(volatile u_int32_t *)addr = val;
>> +*(volatile uint32_t *)addr = val;
>> }
>>
>> -static inline void iowrite16(u16 val, volatile void *addr)
>> +static inline void iowrite16(uint16_t val, volatile void *addr)
>> {
>> -*(volatile u16 *)addr = val;
>> +*(volatile uint16_t *)addr = val;
>> }
>>
>> -static inline void iowrite8(u_int8_t val, volatile void *addr)
>> +static inline void iowrite8(uint8_t val, volatile void *addr)
>> {
>> -*(volatile u_int8_t *)addr = val;
>> +*(volatile uint8_t *)addr = val;
>> }
>>
>> static inline unsigned int readl(volatile void __iomem *addr)
>> diff --git a/lib/librte_pmd_enic/enic_main.c
>>b/lib/librte_pmd_enic/enic_main.c
>> index f6f00d3..853dd04 100644
>> --- a/lib/librte_pmd_enic/enic_main.c
>> +++ b/lib/librte_pmd_enic/enic_main.c
>> @@ -172,17 +172,17 @@ unsigned int enic_cleanup_wq(struct enic *enic,
>>struct vnic_wq *wq)
>>
>> int enic_send_pkt(struct enic *enic, struct vnic_wq *wq,
>> struct rte_mbuf *tx_pkt, unsigned short len,
>> -u_int8_t sop, u_int8_t eop,
>> -u_int16_t ol_flags, u_int16_t vlan_tag)
>> +uint8_t sop, uint8_t eop,
>> +uint16_t ol_flags, uint16_t vlan_tag)
>> {
>> struct wq_enet_desc *desc = vnic_wq_next_desc(wq);
>> -u_int16_t mss = 0;
>> -u_int16_t header_length = 0;
>> -u_int8_t cq_entry = eop;
>> -u_int8_t vlan_tag_insert = 0;
>> +uint16_t mss = 0;
>> +uint16_t header_length = 0;
>> +uint8_t cq_entry = eop;
>> +uint8_t vlan_tag_insert = 0;
>> unsigned char *buf = (unsigned char *)(tx_pkt->buf_addr) +
>> RTE_PKTMBUF_HEADROOM;
>> -u_int64_t bus_addr = (dma_addr_t)
>> +uint64_t bus_addr = (dma_addr_t)
>> (tx_pkt->buf_physaddr + RTE_PKTMBUF_HEADROOM);
>>
>> if (sop) {
>> @@ -342,8 +342,8 @@ static int enic_rq_alloc_buf(struct vnic_rq *rq)
>> void *buf;
>> dma_addr_t dma_addr;
>> struct rq_enet_desc *desc = vnic_rq_next_desc(rq);
>> -u_int8_t type = RQ_ENET_TYPE_ONLY_SOP;
>> -u_int16_t len = ENIC_MAX_MTU + VLAN_ETH_HLEN;
>> +uint8_t
[dpdk-dev] [PATCH] enicpmd: compilation error during inclusion of vfio.h
On 28/11/14 1:54 am, "Thomas Monjalon" wrote: >2014-11-27 19:01, Thomas Monjalon: >> 2014-11-27 22:44, Sujith Sankar: >> > Inclusion of vfio.h was giving compilation errors if kernel version >>is less >> > than 3.6.0 and if RTE_EAL_VFIO was on in config. >> > >> > Replaced inclusion of vfio.h with eal_vfio.h and replaced >>RTE_EAL_VFIO with >> > VFIO_PRESENT in enicpmd code. >> >> You should add >> Reported-by: Pawel Wodkowski I shall take care of this from now on. >> >> > Signed-off-by: Sujith Sankar >> [...] >> > CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ >>-I$(RTE_SDK)/lib/librte_pmd_enic/vnic/ >> > CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/ >> > +CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal/ >> > CFLAGS += -O3 -Wno-deprecated >> >> I think -I$(RTE_SDK)/lib/librte_hash/ and >>-I$(RTE_SDK)/lib/librte_eal/linuxapp/eal/ >> are not needed. >> >> I'll fix it if you confirm. You?re right. > >Applied with above comments. Thank you Thomas ! > >-- >Thomas
[dpdk-dev] [PATCH] enicpmd: compilation error during inclusion of vfio.h
On 27/11/14 10:44 pm, "Sujith Sankar (ssujith)" wrote:
>Inclusion of vfio.h was giving compilation errors if kernel version is
>less
>than 3.6.0 and if RTE_EAL_VFIO was on in config.
>
>Replaced inclusion of vfio.h with eal_vfio.h and replaced RTE_EAL_VFIO
>with
>VFIO_PRESENT in enicpmd code.
eal_vfio.h is not included. The inclusion of vfio.h is removed. Sorry
for the error in the description.
>
>Signed-off-by: Sujith Sankar
>---
> lib/librte_pmd_enic/Makefile| 1 +
> lib/librte_pmd_enic/enic_main.c | 13 +
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
>diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile
>index d4c2f66..befc552 100644
>--- a/lib/librte_pmd_enic/Makefile
>+++ b/lib/librte_pmd_enic/Makefile
>@@ -39,6 +39,7 @@ LIB = librte_pmd_enic.a
>
> CFLAGS += -I$(RTE_SDK)/lib/librte_hash/
>-I$(RTE_SDK)/lib/librte_pmd_enic/vnic/
> CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/
>+CFLAGS += -I$(RTE_SDK)/lib/librte_eal/linuxapp/eal/
> CFLAGS += -O3 -Wno-deprecated
>
> VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src
>diff --git a/lib/librte_pmd_enic/enic_main.c
>b/lib/librte_pmd_enic/enic_main.c
>index 4b857bb..f6f00d3 100644
>--- a/lib/librte_pmd_enic/enic_main.c
>+++ b/lib/librte_pmd_enic/enic_main.c
>@@ -39,9 +39,6 @@
> #include
> #include
> #include
>-#ifdef RTE_EAL_VFIO
>-#include
>-#endif
>
> #include
> #include
>@@ -631,7 +628,7 @@ int enic_enable(struct enic *enic)
>
> vnic_dev_enable_wait(enic->vdev);
>
>-#ifndef RTE_EAL_VFIO
>+#ifndef VFIO_PRESENT
> /* Register and enable error interrupt */
> rte_intr_callback_register(&(enic->pdev->intr_handle),
> enic_intr_handler, (void *)enic->rte_dev);
>@@ -995,7 +992,7 @@ int enic_setup_finish(struct enic *enic)
> return 0;
> }
>
>-#ifdef RTE_EAL_VFIO
>+#ifdef VFIO_PRESENT
> static void enic_eventfd_init(struct enic *enic)
> {
> enic->eventfd = enic->pdev->intr_handle.fd;
>@@ -1033,7 +1030,7 @@ int enic_get_link_status(struct enic *enic)
> }
>
>
>-#ifdef RTE_EAL_VFIO
>+#ifdef VFIO_PRESENT
> static int enic_create_err_intr_thread(struct enic *enic)
> {
> pthread_attr_t intr_attr;
>@@ -,7 +1108,7 @@ static void enic_dev_deinit(struct enic *enic)
> if (eth_dev->data->mac_addrs)
> rte_free(eth_dev->data->mac_addrs);
>
>-#ifdef RTE_EAL_VFIO
>+#ifdef VFIO_PRESENT
> enic_clear_intr_mode(enic);
> #endif
> }
>@@ -1167,7 +1164,7 @@ static int enic_dev_init(struct enic *enic)
> */
> enic_get_res_counts(enic);
>
>-#ifdef RTE_EAL_VFIO
>+#ifdef VFIO_PRESENT
> /* Set interrupt mode based on resource counts and system
>* capabilities
>*/
>--
>1.9.1
>
[dpdk-dev] [PATCH] config: disable enic driver on Power
Hi David, I shall take a look at it get back soon after some tests. One point here is that ENICPMD will be used only on UCS servers (as Cisco VIC cards are shipped only with them) and they are all x86_64. So you could turn it off for all the other architectures. Thanks, -Sujith From: David Marchand mailto:david.march...@6wind.com>> Date: Thursday, 27 November 2014 5:14 pm To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>> Cc: Chao Zhu mailto:chaozhu at linux.vnet.ibm.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>> Subject: Re: [PATCH] config: disable enic driver on Power Hello Sujith, Please can you have a look at this in your enic driver ? I find it weird to use these types while we could use types such as uint8_t etc... Thanks. -- David Marchand On Thu, Nov 27, 2014 at 12:42 PM, David Marchand mailto:david.marchand at 6wind.com>> wrote: enic driver is giving trouble because of non-standard types : CC enic_res.o In file included from lib/librte_pmd_enic/enic_res.c:36:0: lib/librte_pmd_enic/enic_compat.h:92:1: error: unknown type name ?u_int32_t? static inline u_int32_t ioread32(volatile void *addr) ^ Disable it on Power for now. Signed-off-by: David Marchand mailto:david.marchand at 6wind.com>> --- config/defconfig_ppc_64-power8-linuxapp-gcc |1 + 1 file changed, 1 insertion(+) diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc index cefb3be..48018c3 100644 --- a/config/defconfig_ppc_64-power8-linuxapp-gcc +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc @@ -52,6 +52,7 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n CONFIG_RTE_LIBRTE_VIRTIO_PMD=n CONFIG_RTE_LIBRTE_VMXNET3_PMD=n CONFIG_RTE_LIBRTE_PMD_BOND=n +CONFIG_RTE_LIBRTE_ENIC_PMD=n # This following libraries are not available on Power. So they're turned off. CONFIG_RTE_LIBRTE_LPM=n -- 1.7.10.4
[dpdk-dev] [PATCH v6 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD
Thanks Thomas, David and Neil ! I shall work on finishing the documentation. About that, you had mentioned that you wanted it in doc/drivers/ path. Could I send a patch with documentation in the path doc/drivers/enicpmd/ ? Thanks, -Sujith On 27/11/14 3:41 am, "Thomas Monjalon" wrote: >> > ENIC PMD is the poll-mode driver for the Cisco Systems Inc. VIC to be >> > used with DPDK suite. >> > >> > Sujith Sankar (6): >> > enicpmd: License text >> > enicpmd: Makefile >> > enicpmd: VNIC common code partially shared with ENIC kernel mode >> > driver >> > enicpmd: pmd specific code >> > enicpmd: DPDK-ENIC PMD interface >> > enicpmd: DPDK changes for accommodating ENIC PMD >> > >> >> Acked-by: David Marchand >> >> Thanks Sujith. > >Applied and enabled in BSD configuration (not tested). > >It would be nice to have some documentation for this driver now. > >Thanks >-- >Thomas
[dpdk-dev] [PATCH v5 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD
Thanks David. I shall rectify those. Regards, -Sujith From: David Marchand mailto:david.march...@6wind.com>> Date: Tuesday, 25 November 2014 8:58 pm To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>> Cc: "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>>, "Prasad Rao (prrao)" mailto:prrao at cisco.com>> Subject: Re: [dpdk-dev] [PATCH v5 0/6] enicpmd: Cisco Systems Inc. VIC Ethernet PMD Sujith, - Sorry, I still have one problem with the patchset. Your patches do not pass checkpatch. I can see indent problems, trailing whitespaces etc... Can you fix this ? - Also, look at patch 6/6, there is a problem with the build option (see my other mail). Thanks for the effort. -- David Marchand On Wed, Nov 26, 2014 at 12:45 AM, Sujith Sankar mailto:ssujith at cisco.com>> wrote: ENIC PMD is the poll-mode driver for the Cisco Systems Inc. VIC to be used with DPDK suite. Sujith Sankar (6): enicpmd: License text enicpmd: Makefile enicpmd: VNIC common code partially shared with ENIC kernel mode driver enicpmd: pmd specific code enicpmd: DPDK-ENIC PMD interface enicpmd: DPDK changes for accommodating ENIC PMD config/common_linuxapp |5 + lib/Makefile |1 + lib/librte_pmd_enic/LICENSE | 27 + lib/librte_pmd_enic/Makefile | 67 ++ lib/librte_pmd_enic/enic.h | 157 lib/librte_pmd_enic/enic_clsf.c | 244 ++ lib/librte_pmd_enic/enic_compat.h| 142 lib/librte_pmd_enic/enic_etherdev.c | 613 +++ lib/librte_pmd_enic/enic_main.c | 1266 ++ lib/librte_pmd_enic/enic_res.c | 221 ++ lib/librte_pmd_enic/enic_res.h | 168 lib/librte_pmd_enic/vnic/cq_desc.h | 126 +++ lib/librte_pmd_enic/vnic/cq_enet_desc.h | 261 ++ lib/librte_pmd_enic/vnic/rq_enet_desc.h | 76 ++ lib/librte_pmd_enic/vnic/vnic_cq.c | 117 +++ lib/librte_pmd_enic/vnic/vnic_cq.h | 152 lib/librte_pmd_enic/vnic/vnic_dev.c | 1063 + lib/librte_pmd_enic/vnic/vnic_dev.h | 202 + lib/librte_pmd_enic/vnic/vnic_devcmd.h | 774 ++ lib/librte_pmd_enic/vnic/vnic_enet.h | 78 ++ lib/librte_pmd_enic/vnic/vnic_intr.c | 83 ++ lib/librte_pmd_enic/vnic/vnic_intr.h | 126 +++ lib/librte_pmd_enic/vnic/vnic_nic.h | 88 +++ lib/librte_pmd_enic/vnic/vnic_resource.h | 97 +++ lib/librte_pmd_enic/vnic/vnic_rq.c | 246 ++ lib/librte_pmd_enic/vnic/vnic_rq.h | 282 +++ lib/librte_pmd_enic/vnic/vnic_rss.c | 85 ++ lib/librte_pmd_enic/vnic/vnic_rss.h | 61 ++ lib/librte_pmd_enic/vnic/vnic_stats.h| 86 ++ lib/librte_pmd_enic/vnic/vnic_wq.c | 245 ++ lib/librte_pmd_enic/vnic/vnic_wq.h | 283 +++ lib/librte_pmd_enic/vnic/wq_enet_desc.h | 114 +++ mk/rte.app.mk<http://rte.app.mk>|4 + 33 files changed, 7560 insertions(+) create mode 100644 lib/librte_pmd_enic/LICENSE create mode 100644 lib/librte_pmd_enic/Makefile create mode 100644 lib/librte_pmd_enic/enic.h create mode 100644 lib/librte_pmd_enic/enic_clsf.c create mode 100644 lib/librte_pmd_enic/enic_compat.h create mode 100644 lib/librte_pmd_enic/enic_etherdev.c create mode 100644 lib/librte_pmd_enic/enic_main.c create mode 100644 lib/librte_pmd_enic/enic_res.c create mode 100644 lib/librte_pmd_enic/enic_res.h create mode 100644 lib/librte_pmd_enic/vnic/cq_desc.h create mode 100644 lib/librte_pmd_enic/vnic/cq_enet_desc.h create mode 100644 lib/librte_pmd_enic/vnic/rq_enet_desc.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_cq.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_cq.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_dev.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_dev.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_devcmd.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_enet.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_intr.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_intr.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_nic.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_resource.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_rq.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_rq.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_rss.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_rss.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_stats.h create mode 100644 lib/librte_pmd_enic/vnic/vnic_wq.c create mode 100644 lib/librte_pmd_enic/vnic/vnic_wq.h create mode 100644 lib/librte_pmd_enic/vnic/wq_enet_desc.h -- 1.9.1
[dpdk-dev] [PATCH v3 6/6] DPDK changes for accommodating ENIC PMD
On 24/11/14 5:47 am, "Neil Horman" wrote:
>On Sun, Nov 23, 2014 at 09:38:19PM +0530, Sujith Sankar wrote:
>> Signed-off-by: Sujith Sankar
>> ---
>> config/common_linuxapp | 5 +
>> lib/Makefile | 1 +
>> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 7 +++
>> lib/librte_eal/linuxapp/eal/include/eal_pci_init.h | 1 +
>> mk/rte.app.mk | 4
>> 5 files changed, 18 insertions(+)
>>
>> diff --git a/config/common_linuxapp b/config/common_linuxapp
>> index 57b61c9..3c091e7 100644
>> --- a/config/common_linuxapp
>> +++ b/config/common_linuxapp
>> @@ -210,6 +210,11 @@ CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
>> CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
>>
>> #
>> +# Compile burst-oriented Cisco ENIC PMD driver
>> +#
>> +CONFIG_RTE_LIBRTE_ENIC_PMD=y
>> +
>> +#
>> # Compile burst-oriented VIRTIO PMD driver
>> #
>> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
>> diff --git a/lib/Makefile b/lib/Makefile
>> index e3237ff..1911790 100644
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@ -43,6 +43,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += librte_cmdline
>> DIRS-$(CONFIG_RTE_LIBRTE_ETHER) += librte_ether
>> DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += librte_pmd_e1000
>> DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += librte_pmd_ixgbe
>> +DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += librte_pmd_enic
>> DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += librte_pmd_i40e
>> DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond
>> DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += librte_pmd_ring
>> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>>b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> index c776ddc..6bf8f2e 100644
>> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
>> @@ -736,6 +736,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
>> maps[i].offset = reg.offset;
>> maps[i].size = reg.size;
>> dev->mem_resource[i].addr = bar_addr;
>> +dev->mem_resource[i].len = reg.size;
>> }
>>
>> /* if secondary process, do not set up interrupts */
>> @@ -791,4 +792,10 @@ pci_vfio_is_enabled(void)
>> {
>> return vfio_cfg.vfio_enabled;
>> }
>> +
>> +int
>> +pci_vfio_container_fd(void)
>> +{
>> +return vfio_cfg.vfio_container_fd;
>> +}
>You should move this function definition to a separate patch and put it
>earlier
>in the series, as you call this function two patches back.
Thanks for the comment, Neil. I shall move this to a separate patch and
put it earlier in the series.
>
>Also, this gives me pause, as it seems like you're working around the
>VFIO api.
>From what I see, you just use this to get an fd that you can use in an
>ioctl to
>set some DMA settings. First off, theres already a function called
>pci_vfio_get_container_fd, which does exactly what you are doing here,
>with
>additional safety checking.
>
>However, even though there is an existing function to do what you want, I
>would
>recommend that you not use it for your purposes. Whenever you expose
>something
>like a file descriptor, you run the risk of multiple accessors racing
>trying to
>set/unset features and preform operations. It would be better if you
>could add
>apropriate api calls to vfio interface to set what you want. That way the
>library can add appropriate locking if/when needed
I see that vfio_cfg.vfio_container_fd is obtained and stored in
pci_vfio_enable(), and this is not modified later.
ENIC PMD needs it to add the IOMMU mapping for buffers used for
communicating with adapter firmware. That?s just adding an entry, and
container fd is just passed as an argument. So the following addition in
eal_pci_vfio.c should be sufficient. Since vfio_cfg is per process, I do
not think that any other checking is required.
int
pci_vfio_map_dma(struct vfio_iommu_type1_dma_map *dma_map)
{
return ioctl(vfio_cfg.vfio_container_fd, VFIO_IOMMU_MAP_DMA, dma_map);
}
Does this look alright? Do you think that I?ve missed out anything here?
Thanks,
-Sujith
>
>Neil
>
>> #endif
>> diff --git a/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h
>>b/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h
>> index d758bee..c9e9e40 100644
>> --- a/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h
>> +++ b/lib/librte_eal/linuxapp/eal/include/eal_pci_init.h
>> @@ -71,6 +71,7 @@ int pci_uio_map_resource(struct rte_pci_device *dev);
>>
>> int pci_vfio_enable(void);
>> int pci_vfio_is_enabled(void);
>> +int pci_vfio_container_fd(void);
>> int pci_vfio_mp_sync_setup(void);
>>
>> /* map VFIO resource prototype */
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>> index 285b65c..95c652f 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -186,6 +186,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_VMXNET3_PMD),y)
>> LDLIBS += -lrte_pmd_vmxnet3_uio
>> endif
>>
>> +ifeq ($(CONFIG_RTE_LIBRTE_ENIC_PMD),y)
>> +LDLIBS += -lrte_pmd_enic
>> +endif
>> +
>> ifeq
[dpdk-dev] [PATCH v2 5/6] DPDK-ENIC PMD interface
Thanks for the comments, Neil. I shall include those in v3.
Regards,
-Sujith
On 21/11/14 6:54 pm, "Neil Horman" wrote:
>On Fri, Nov 21, 2014 at 10:03:02PM +0530, Sujith Sankar wrote:
>> Signed-off-by: Sujith Sankar
>> ---
>> lib/librte_pmd_enic/enic_etherdev.c | 620
>>
>> 1 file changed, 620 insertions(+)
>> create mode 100644 lib/librte_pmd_enic/enic_etherdev.c
>>
>> diff --git a/lib/librte_pmd_enic/enic_etherdev.c
>>b/lib/librte_pmd_enic/enic_etherdev.c
>> new file mode 100644
>> index 000..90003f5
>> --- /dev/null
>> +++ b/lib/librte_pmd_enic/enic_etherdev.c
>> @@ -0,0 +1,620 @@
>> +/*
>> + * Copyright 2008-2014 Cisco Systems, Inc. All rights reserved.
>> + * Copyright 2007 Nuova Systems, Inc. All rights reserved.
>> + *
>> + * Copyright (c) 2014, Cisco Systems, Inc.
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + *
>> + * 1. Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + *
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in
>> + * the documentation and/or other materials provided with the
>> + * distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
>> + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>> + * COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>> + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
>> + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
>> + * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
>> + * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
>> + * POSSIBILITY OF SUCH DAMAGE.
>> + *
>> + */
>> +#ident "$Id$"
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "vnic_intr.h"
>> +#include "vnic_cq.h"
>> +#include "vnic_wq.h"
>> +#include "vnic_rq.h"
>> +#include "vnic_enet.h"
>> +#include "enic.h"
>> +
>> +#ifdef RTE_LIBRTE_ENIC_PMD_DEBUG_TRACE
>> +#define ENICPMD_FUNC_TRACE()\
>> +do { \
>> +dev_trace(enic, "Entering %s\n", __func__); \
>> +} while (0)
>You probably want to convert this to use:
>rte_log(RTE_LOG_DEBUG, RTE_LOGTYPE_PMD, ...)
>Currently you have dev_trace defined to printf, which won't work well on
>systems
>that have stdout/err closed.
>
>Also, you don't need the do{}while(0) construct here just don't add the
>semicolon after the rte_log call, and you'll get the same behavior
>
>converting to rte_log will also let you remove the DEBUG_TRACE ifdef as
>you can
>just enable PMD log types and DEBUG log levels via the log api
>
>> +#else
>> +#define ENICPMD_FUNC_TRACE()
>> +#endif
>> +
>> +
>> +/*
>> + * The set of PCI devices this driver supports
>> + */
>> +static struct rte_pci_id pci_id_enic_map[] = {
>> +#define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev) {RTE_PCI_DEVICE(vend,
>>dev)},
>> +#ifndef PCI_VENDOR_ID_CISCO
>> +#define PCI_VENDOR_ID_CISCO 0x1137
>> +#endif
>> +#include "rte_pci_dev_ids.h"
>> +RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>>PCI_DEVICE_ID_CISCO_VIC_ENET)
>> +RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO,
>>PCI_DEVICE_ID_CISCO_VIC_ENET_VF)
>> +{.vendor_id = 0, /* Sentinal */},
>> +};
>> +
>> +int enicpmd_fdir_remove_perfect_filter(struct rte_eth_dev *eth_dev,
>> +struct rte_fdir_filter *fdir_filter,
>> +uint16_t soft_id)
>> +{
>> +struct enic *enic = pmd_priv(eth_dev);
>> +
>> +ENICPMD_FUNC_TRACE();
>> +return enic_fdir_del_fltr(enic, fdir_filter);
>> +}
>> +
>> +int enicpmd_fdir_add_perfect_filter(struct rte_eth_dev *eth_dev,
>> +struct rte_fdir_filter *fdir_filter, uint16_t soft_id,
>> +uint8_t queue, uint8_t drop)
>> +{
>> +struct enic *enic = pmd_priv(eth_dev);
>> +
>> +ENICPMD_FUNC_TRACE();
>> +return enic_fdir_add_fltr(enic, fdir_filter, (uint16_t)queue, drop);
>> +}
>> +
>> +void enicpmd_fdir_info_get(struct rte_eth_dev *eth_dev,
>> +struct rte_eth_fdir *fdir)
>> +{
>> +struct enic *enic = pmd_priv(eth_dev);
>> +
>> +ENICPMD_FUNC_TRACE();
>> +*fdir = enic->fdir.stats;
>> +}
>> +
>The three functions above should be static, as their exported via the
>device
>structure below. You don't want people able to call them directly.
>
>> +void enicpmd_dev_tx_queue_release(void *txq)
>> +{
>> +ENICPMD_FUNC_TRACE();
>> +
[dpdk-dev] [PATCH v2 2/6] ENIC PMD Makefile
On 21/11/14 5:03 pm, "Neil Horman" wrote: >On Fri, Nov 21, 2014 at 10:02:59PM +0530, Sujith Sankar wrote: >> Signed-off-by: Sujith Sankar >> --- >> lib/librte_pmd_enic/Makefile | 67 >> >> 1 file changed, 67 insertions(+) >> create mode 100644 lib/librte_pmd_enic/Makefile >> >> diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile >> new file mode 100644 >> index 000..2073cd6 >> --- /dev/null >> +++ b/lib/librte_pmd_enic/Makefile >> @@ -0,0 +1,67 @@ >> +# BSD LICENSE >> +# >> +# Copyright(c) 2010-2013 Intel Corporation. All rights reserved. >> +# All rights reserved. >> +# >This should be (c) Cisco, shouldn't it? This file was taken from DPDK source and modified. Hence I thought I should be retaining the copyright. Please let me know if this is not right. > >> +# Redistribution and use in source and binary forms, with or without >> +# modification, are permitted provided that the following conditions >> +# are met: >> +# >> +# * Redistributions of source code must retain the above copyright >> +# notice, this list of conditions and the following disclaimer. >> +# * Redistributions in binary form must reproduce the above >>copyright >> +# notice, this list of conditions and the following disclaimer >>in >> +# the documentation and/or other materials provided with the >> +# distribution. >> +# * Neither the name of Intel Corporation nor the names of its >> +# contributors may be used to endorse or promote products >>derived >> +# from this software without specific prior written permission. >> +# >> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND >>CONTRIBUTORS >> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS >>FOR >> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE >>COPYRIGHT >> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, >>INCIDENTAL, >> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF >>USE, >> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON >>ANY >> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR >>TORT >> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE >>USE >> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH >>DAMAGE. >> +# >> + >> +include $(RTE_SDK)/mk/rte.vars.mk >> + >> +# >> +# library name >> +# >> +LIB = librte_pmd_enic.a >> + >> +CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ >>-I$(RTE_SDK)/lib/librte_pmd_enic/ >> +CFLAGS += -I$(RTE_SDK)/lib/librte_pmd_enic/vnic/ >> +CFLAGS += -O3 -Wno-deprecated >> + >> +VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src >> + >> +# >> +# all source are stored in SRCS-y >> +# >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_main.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_clsf.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_cq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_wq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_dev.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_intr.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_rq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_etherdev.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_res.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic/vnic_rss.c >> + >> + >> +# this lib depends upon: >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_eal >>lib/librte_ether >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_mempool >>lib/librte_mbuf >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net >>lib/librte_malloc >> + >> +include $(RTE_SDK)/mk/rte.lib.mk >> + >> -- >> 1.9.1 >> >>
[dpdk-dev] [PATCH v2 0/6] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD
Hi David, Since the kernel version is less than 3.6.0, support for VFIO is not there. Could you please turn off VFIO in config/common_linuxapp and try with IGB_UIO? Thanks, -Sujith From: David Marchand mailto:david.march...@6wind.com>> Date: Friday, 21 November 2014 3:22 pm To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>> Cc: "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>> Subject: Re: [dpdk-dev] [PATCH v2 0/6] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD Hello Sujith, I just tried your patchset on my system but I can't get it to build : $ make config T=x86_64-native-linuxapp-gcc && make Configuration done == Build scripts == Build scripts/testhost HOSTCC testhost.o [snip] == Build lib/librte_pmd_enic CC enic_main.o ../lib/librte_pmd_enic/enic_main.c:43:24: fatal error: linux/vfio.h: No such file or directory compilation terminated. make[3]: *** [enic_main.o] Error 1 make[2]: *** [librte_pmd_enic] Error 2 make[1]: *** [lib] Error 2 make: *** [all] Error 2 Looks like there is a problem with detecting vfio support and/or including the right header. $ uname -a Linux ... 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux Regards, -- David Marchand
[dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD
Thanks for the clear response. I?ll take a look at it. Regards, -Sujith On 10/11/14 3:33 pm, "Thomas Monjalon" wrote: >2014-11-10 09:27, Sujith Sankar: >> On 07/11/14 9:17 pm, "Thomas Monjalon" >>wrote: >> >It seems that this PMD is based on DPDK 1.7. >> >Could you rebase it on HEAD? >> >> This patch is based on 1.7.1. Thought that is the latest. And I got >>the >> diff from origin. >> What made you feel that the patch is from 1.7? > >By saying 1.7, I meant 1.7.0 or 1.7.1. >In current HEAD (future 1.8.0), there is a lot of changes which make your >PMD >incompatible. That's why the rule is to base the patches on the latest >HEAD. > >Thanks for your efforts. >-- >Thomas
[dpdk-dev] [PATCH 3/7] ENIC PMD Makefile
Neil, If I move the DPDK patch that accommodates ENIC PMD (that is the one that patches lib/Makefile) to the last in the series, builds between commits would succeed, wouldn?t it? Moving that to the last is anyway needed. Thanks, -Sujith On 07/11/14 9:16 pm, "Sujith Sankar (ssujith)" wrote: >Hi Neil, > >Thanks for the comments. I shall work on the modifications that you have >suggested and get back with V2. > >Regards, >-Sujith > >On 07/11/14 5:04 pm, "Neil Horman" wrote: > >>On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote: >>> Signed-off-by: Sujith Sankar >>> --- >>> lib/librte_pmd_enic/Makefile | 66 >>> >>> 1 file changed, 66 insertions(+) >>> create mode 100644 lib/librte_pmd_enic/Makefile >>> >>> diff --git a/lib/librte_pmd_enic/Makefile >>>b/lib/librte_pmd_enic/Makefile >>> new file mode 100644 >>> index 000..7605a8f >>> --- /dev/null >>> +++ b/lib/librte_pmd_enic/Makefile >>> @@ -0,0 +1,66 @@ >>> +# BSD LICENSE >>> +# >>> +# Copyright(c) 2010-2013 Intel Corporation. All rights reserved. >>> +# All rights reserved. >>> +# >>> +# Redistribution and use in source and binary forms, with or without >>> +# modification, are permitted provided that the following conditions >>> +# are met: >>> +# >>> +# * Redistributions of source code must retain the above copyright >>> +# notice, this list of conditions and the following disclaimer. >>> +# * Redistributions in binary form must reproduce the above >>>copyright >>> +# notice, this list of conditions and the following disclaimer >>>in >>> +# the documentation and/or other materials provided with the >>> +# distribution. >>> +# * Neither the name of Intel Corporation nor the names of its >>> +# contributors may be used to endorse or promote products >>>derived >>> +# from this software without specific prior written permission. >>> +# >>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND >>>CONTRIBUTORS >>> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >>> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS >>>FOR >>> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE >>>COPYRIGHT >>> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, >>>INCIDENTAL, >>> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >>> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF >>>USE, >>> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON >>>ANY >>> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR >>>TORT >>> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE >>>USE >>> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH >>>DAMAGE. >>> +# >>> + >>> +include $(RTE_SDK)/mk/rte.vars.mk >>> + >>> +# >>> +# library name >>> +# >>> +LIB = librte_pmd_enic.a >>> + >>> +CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ >>> +CFLAGS += -O3 -Wno-deprecated >>> + >>> +VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src >>> + >>> +# >>> +# all source are stored in SRCS-y >>> +# >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_main.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_clsf.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_cq.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_wq.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_dev.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_intr.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rq.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_etherdev.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_res.c >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rss.c >>> + >>> + >>> +# this lib depends upon: >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_eal >>>lib/librte_ether >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_mempool >>>lib/librte_mbuf >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net >>>lib/librte_malloc >>> + >>> +include $(RTE_SDK)/mk/rte.lib.mk >>> + >>> -- >>> 1.9.1 >>> >>> >> >>Make this the last patch in your series, and merge it with the chunk from >>the >>last patch that adds the enic directory to the lib/Makefile, so that a >>bisect >>will build between these commits. >> >>Neil >> >
[dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD
Thomas, It is our pleasure to be part of the community and to be contributing to it. Looking forward to a healthy and fruitful association. Thanks and Regards, -Sujith On 07/11/14 4:39 pm, "Thomas Monjalon" wrote: >2014-11-08 01:35, Sujith Sankar: >> ENIC PMD is the poll-mode driver for the Cisco Systems Inc. VIC to be >> used with DPDK suite. > >Great to see you on board! > >Thank you to contribute a new driver. > >-- >Thomas
[dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD
Thomas, This patch is based on 1.7.1. Thought that is the latest. And I got the diff from origin. What made you feel that the patch is from 1.7? Regards, -Sujith On 07/11/14 9:17 pm, "Thomas Monjalon" wrote: >Sujith, > >It seems that this PMD is based on DPDK 1.7. >Could you rebase it on HEAD? > >Thank you >-- >Thomas
[dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD
Thomas, Let me work on that too. Thanks, -Sujith On 07/11/14 9:17 pm, "Thomas Monjalon" wrote: >Sujith, > >It seems that this PMD is based on DPDK 1.7. >Could you rebase it on HEAD? > >Thank you >-- >Thomas
[dpdk-dev] [PATCH 7/7] Release notes for ENIC PMD 1.0.0.3
Hi Thomas, Thank you for the comments. I?ll work on moving the release notes to rst and add performance numbers with testpmd. Once I fix these and Neil?s comments, I shall get back with version 2. Thanks, -Sujith On 07/11/14 5:50 pm, "Thomas Monjalon" wrote: >Many informations in the release notes are not well adapted to an >integration. >Please could you rework it? >I'd like to create a doc directory for drivers (doc/drivers) as >doc/guides. >So this doc should be in rst format in order to be processed by sphinx and >published on the web site (like guides). >Could you also include a performance test report based on testpmd? > >Thanks a lot >-- >Thomas
[dpdk-dev] [PATCH 3/7] ENIC PMD Makefile
Hi Neil, Thanks for the comments. I shall work on the modifications that you have suggested and get back with V2. Regards, -Sujith On 07/11/14 5:04 pm, "Neil Horman" wrote: >On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote: >> Signed-off-by: Sujith Sankar >> --- >> lib/librte_pmd_enic/Makefile | 66 >> >> 1 file changed, 66 insertions(+) >> create mode 100644 lib/librte_pmd_enic/Makefile >> >> diff --git a/lib/librte_pmd_enic/Makefile b/lib/librte_pmd_enic/Makefile >> new file mode 100644 >> index 000..7605a8f >> --- /dev/null >> +++ b/lib/librte_pmd_enic/Makefile >> @@ -0,0 +1,66 @@ >> +# BSD LICENSE >> +# >> +# Copyright(c) 2010-2013 Intel Corporation. All rights reserved. >> +# All rights reserved. >> +# >> +# Redistribution and use in source and binary forms, with or without >> +# modification, are permitted provided that the following conditions >> +# are met: >> +# >> +# * Redistributions of source code must retain the above copyright >> +# notice, this list of conditions and the following disclaimer. >> +# * Redistributions in binary form must reproduce the above >>copyright >> +# notice, this list of conditions and the following disclaimer >>in >> +# the documentation and/or other materials provided with the >> +# distribution. >> +# * Neither the name of Intel Corporation nor the names of its >> +# contributors may be used to endorse or promote products >>derived >> +# from this software without specific prior written permission. >> +# >> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND >>CONTRIBUTORS >> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT >> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS >>FOR >> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE >>COPYRIGHT >> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, >>INCIDENTAL, >> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT >> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF >>USE, >> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON >>ANY >> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR >>TORT >> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE >>USE >> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH >>DAMAGE. >> +# >> + >> +include $(RTE_SDK)/mk/rte.vars.mk >> + >> +# >> +# library name >> +# >> +LIB = librte_pmd_enic.a >> + >> +CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ >> +CFLAGS += -O3 -Wno-deprecated >> + >> +VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src >> + >> +# >> +# all source are stored in SRCS-y >> +# >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_main.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_clsf.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_cq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_wq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_dev.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_intr.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rq.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_etherdev.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_res.c >> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rss.c >> + >> + >> +# this lib depends upon: >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_eal >>lib/librte_ether >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_mempool >>lib/librte_mbuf >> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net >>lib/librte_malloc >> + >> +include $(RTE_SDK)/mk/rte.lib.mk >> + >> -- >> 1.9.1 >> >> > >Make this the last patch in your series, and merge it with the chunk from >the >last patch that adds the enic directory to the lib/Makefile, so that a >bisect >will build between these commits. > >Neil >
[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK
Thank you Anatoly ! I?ll do that and get back in case of questions. Regards, -Sujith On 08/09/14 2:00 pm, "Burakov, Anatoly" wrote: >Hi Sujith > >Of course you can. Just use the igb_uio driver instead. Refer to the >Getting Started Guide from Intel, it'll walk you through the steps, >although they are basically the same as for VFIO. > >Thanks, >Anatoly > >-Original Message- >From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com] >Sent: Monday, September 8, 2014 9:28 AM >To: Burakov, Anatoly; Stephen Hemminger >Cc: dev at dpdk.org >Subject: Re: [dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to >DPDK > >Anatoly, >Thanks for the quick response ! > >I am able do PCI passthrough and use the NIC in the guest OS. >What I?m trying to do is run DPDK in the guest and make use of the >passed-through NIC. Without using VFIO, could I achieve this? > >Thanks, >-Sujith > >On 08/09/14 1:51 pm, "Burakov, Anatoly" wrote: > >>Hi Sujith >> >>Not that I know of, no. There are other ways to run physical NICs in a >>VM though, you don't require VFIO for that. >> >>Thanks, >>Anatoly >> >>-Original Message- >>From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com] >>Sent: Monday, September 8, 2014 9:20 AM >>To: Burakov, Anatoly; Stephen Hemminger >>Cc: dev at dpdk.org >>Subject: Re: [dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to >>DPDK >> >>Hi Anatoly, >> >>Has anything happened in this front? Do you see running of DPDK in >>guest OS on KVM with physical NIC passed through to it happening soon? >> >>Thanks, >>-Sujith >> >>On 02/05/14 2:28 pm, "Burakov, Anatoly" >>wrote: >> >>>Hi Stephen, >>> >>>> Will this work in guest? or only on bare metal? >>> >>>VFIO is Linux-only, and in theory will be able to work on the guest, >>>but not at the moment, since it requires IOMMU. There was a GSoC >>>proposal for KVM to do IOMMU implementation, and there were a few AMD >>>IOMMU-emulation patches floating around the KVM lists for some time, >>>but nothing has made it into release yet. >>> >>>Best regards, >>>Anatoly Burakov >>>DPDK SW Engineer >>> >>>-- >>>Intel Shannon Limited >>>Registered in Ireland >>>Registered Office: Collinstown Industrial Park, Leixlip, County >>>Kildare Registered Number: 308263 Business address: Dromore House, >>>East Park, Shannon, Co. Clare >>> >>> >>> >> >
[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK
Anatoly, Thanks for the quick response ! I am able do PCI passthrough and use the NIC in the guest OS. What I?m trying to do is run DPDK in the guest and make use of the passed-through NIC. Without using VFIO, could I achieve this? Thanks, -Sujith On 08/09/14 1:51 pm, "Burakov, Anatoly" wrote: >Hi Sujith > >Not that I know of, no. There are other ways to run physical NICs in a VM >though, you don't require VFIO for that. > >Thanks, >Anatoly > >-----Original Message- >From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com] >Sent: Monday, September 8, 2014 9:20 AM >To: Burakov, Anatoly; Stephen Hemminger >Cc: dev at dpdk.org >Subject: Re: [dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to >DPDK > >Hi Anatoly, > >Has anything happened in this front? Do you see running of DPDK in guest >OS on KVM with physical NIC passed through to it happening soon? > >Thanks, >-Sujith > >On 02/05/14 2:28 pm, "Burakov, Anatoly" wrote: > >>Hi Stephen, >> >>> Will this work in guest? or only on bare metal? >> >>VFIO is Linux-only, and in theory will be able to work on the guest, >>but not at the moment, since it requires IOMMU. There was a GSoC >>proposal for KVM to do IOMMU implementation, and there were a few AMD >>IOMMU-emulation patches floating around the KVM lists for some time, >>but nothing has made it into release yet. >> >>Best regards, >>Anatoly Burakov >>DPDK SW Engineer >> >>-- >>Intel Shannon Limited >>Registered in Ireland >>Registered Office: Collinstown Industrial Park, Leixlip, County Kildare >>Registered Number: 308263 Business address: Dromore House, East Park, >>Shannon, Co. Clare >> >> >> >
[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK
Hi Anatoly, Has anything happened in this front? Do you see running of DPDK in guest OS on KVM with physical NIC passed through to it happening soon? Thanks, -Sujith On 02/05/14 2:28 pm, "Burakov, Anatoly" wrote: >Hi Stephen, > >> Will this work in guest? or only on bare metal? > >VFIO is Linux-only, and in theory will be able to work on the guest, but >not at the moment, since it requires IOMMU. There was a GSoC proposal for >KVM to do IOMMU implementation, and there were a few AMD IOMMU-emulation >patches floating around the KVM lists for some time, but nothing has made >it into release yet. > >Best regards, >Anatoly Burakov >DPDK SW Engineer > >-- >Intel Shannon Limited >Registered in Ireland >Registered Office: Collinstown Industrial Park, Leixlip, County Kildare >Registered Number: 308263 >Business address: Dromore House, East Park, Shannon, Co. Clare > > >
[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission
Hi Hobywan, We?re still working on benchmarking, and would share the numbers once we are done with it. Could you please elaborate on vectorisation functions? Thanks, -Sujith From: Hobywan Kenoby mailto:hobyw...@hotmail.com>> Date: Friday, 11 July 2014 6:46 pm To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>> Subject: RE: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission Hi Sujith, It makes sens, using VFIO makes a far cleaner implementation. You worked on the performance, could you share some measurements ? Did you introduce vectorization functions as Intel did a while ago? There are allways tradeoffs between pps and latency, do you include documentation to configure the card for one or the other? HK From: ssujith at cisco.com<mailto:ssuj...@cisco.com> To: hobywank at hotmail.com<mailto:hobywank at hotmail.com>; dev at dpdk.org<mailto:dev at dpdk.org> Subject: Re: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission Date: Fri, 11 Jul 2014 07:46:08 + Hi Hobywan, Thanks for the email ! We?ve been working on performance benchmarking. Also, we felt that it would be better to push the driver after Anatoly?s patch (vfio-pci) got in so that we could make the necessary modification before submission. Now that 1.7.0 is out, we are hopeful of submitting the patch soon. Thanks, -Sujith From: Hobywan Kenoby mailto:hobyw...@hotmail.com>> Date: Thursday, 10 July 2014 1:37 am To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>> Subject: RE: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission Hi Sujith, It was exciting to see open source code coming from Cisco ensuring a DPDK application can run on any platform and with any card I haven't seen your patch yet. What happened? HK > Date : Wed, 28 May 2014 08:06 > From : dev [mailto:dev-bounces at dpdk.org] > To : dev at dpdk.org<mailto:dev at dpdk.org> > Subject : [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines > for submission > > > Hi all, > > We have been working on development of poll-mode driver for Cisco VIC > Ethernet NIC and integration of it with DPDK. We would like to submit this > poll-mode driver (ENIC PMD) to the DPDK community so that it could be part > of the DPDK tree. > > Could someone please provide the guidelines and steps to do this? As of > now, ENIC PMD is being tested with DPDK 1.6.0r2. Is it alright to submit a > patch for DPDK 1.6.0r2? > > One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO. Hope > this is acceptable. The following thread in dpdk-dev influenced this > decision. > http://dpdk.org/ml/archives/dev/2013-July/000373.html > > ENIC PMD uses one interrupt per interface and it is used by the NIC for > signalling the driver in case of any error. Since this does not come in > the fast path, it should be acceptable, isn?t it? > > Please give your suggestions and comments. > > Thanks, > -Sujith
[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission
Hi Hobywan, Thanks for the email ! We?ve been working on performance benchmarking. Also, we felt that it would be better to push the driver after Anatoly?s patch (vfio-pci) got in so that we could make the necessary modification before submission. Now that 1.7.0 is out, we are hopeful of submitting the patch soon. Thanks, -Sujith From: Hobywan Kenoby mailto:hobyw...@hotmail.com>> Date: Thursday, 10 July 2014 1:37 am To: "Sujith Sankar (ssujith)" mailto:ssujith at cisco.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" mailto:dev at dpdk.org>> Subject: RE: [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission Hi Sujith, It was exciting to see open source code coming from Cisco ensuring a DPDK application can run on any platform and with any card I haven't seen your patch yet. What happened? HK > Date : Wed, 28 May 2014 08:06 > From : dev [mailto:dev-bounces at dpdk.org] > To : dev at dpdk.org<mailto:dev at dpdk.org> > Subject : [dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines > for submission > > > Hi all, > > We have been working on development of poll-mode driver for Cisco VIC > Ethernet NIC and integration of it with DPDK. We would like to submit this > poll-mode driver (ENIC PMD) to the DPDK community so that it could be part > of the DPDK tree. > > Could someone please provide the guidelines and steps to do this? As of > now, ENIC PMD is being tested with DPDK 1.6.0r2. Is it alright to submit a > patch for DPDK 1.6.0r2? > > One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO. Hope > this is acceptable. The following thread in dpdk-dev influenced this > decision. > http://dpdk.org/ml/archives/dev/2013-July/000373.html > > ENIC PMD uses one interrupt per interface and it is used by the NIC for > signalling the driver in case of any error. Since this does not come in > the fast path, it should be acceptable, isn?t it? > > Please give your suggestions and comments. > > Thanks, > -Sujith
[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission
Thank you Anatoly ! I?ll take a look at it and get back in case of questions. -Sujith On 28/05/14 2:22 pm, "Burakov, Anatoly" wrote: >Hi Sujith, > >> One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO. Hope >> this is acceptable. The following thread in dpdk-dev influenced this >>decision. >> http://dpdk.org/ml/archives/dev/2013-July/000373.html > >You may find this [1] patchset interesting. Basically, it adds native >support for VFIO to do the binding and unbinding in DPDK. Whether it fits >your purposes depends on your code, but hopefully you'll be able to >simplify your code. > >[1] http://dpdk.org/ml/archives/dev/2014-May/002568.html > >Best regards, >Anatoly Burakov >DPDK SW Engineer > > >
[dpdk-dev] PMD for Cisco VIC Ethernet NIC - Request for guidelines for submission
Hi all, We have been working on development of poll-mode driver for Cisco VIC Ethernet NIC and integration of it with DPDK. We would like to submit this poll-mode driver (ENIC PMD) to the DPDK community so that it could be part of the DPDK tree. Could someone please provide the guidelines and steps to do this? As of now, ENIC PMD is being tested with DPDK 1.6.0r2. Is it alright to submit a patch for DPDK 1.6.0r2? One aspect of ENIC PMD is that it works with VFIO-PCI and not UIO. Hope this is acceptable. The following thread in dpdk-dev influenced this decision. http://dpdk.org/ml/archives/dev/2013-July/000373.html ENIC PMD uses one interrupt per interface and it is used by the NIC for signalling the driver in case of any error. Since this does not come in the fast path, it should be acceptable, isn?t it? Please give your suggestions and comments. Thanks, -Sujith
[dpdk-dev] Query on the use of FDIR feature
Hi, Could someone kindly give information about the following aspects of the use of FDIR? It is about adding of flow classification rule using fdir_add_perfect_filter() 1. For SCTP, what are the mandatory fields to be provided in struct rte_fdir_filter ? Is it enough if protocol and src and dst IP addresses are provided? 2. If vlan id is specified in struct rte_fdir_filter, what other fields are mandatory? 3. In the case of IPV6, is it enough if protocol, src and dst IPV6 addresses and src and dst L4 port numbers are provided? 4. Is it mandatory that the applications have to provide protocol, src and dst IPV4 addresses and port numbers when it is trying to add filter for IPV4? The programmers guide does not clarify these, and hence the email to the group. Thanks in advance, -Sujith
[dpdk-dev] Questions on use of multiple NIC interfaces
Hi all, Could someone answer the following questions about the usage of multiple NIC interfaces with DPDK? 1. If my server has two identical Intel NICs, could I use both with DPDK and its applications? 2. If both the NIC cards could be used with DPDK, could I use them with separate instances of applications? E.g., NIC1 used by App1 and NIC2 used by App2. 3. If answer to qn no 2 is yes, does the driver take care to avoid reinitialising NIC1 when App2 tries to initialise NIC2? From what I?ve seen, DPDK calls the driver init for all the matching devices (vendor id and device id). Thanks, -Sujith
[dpdk-dev] A query on the latency numbers
Hi all, In the documentation available on DPDK, I could find the performance numbers in terms of packets per second. Could someone point me to some documentation which gives performance gain of round trip time or packet processing time in terms of time, say, usecs? Also, what is the tool that is widely used for performance benchmarking in the context of DPDK (with and without user-space TCP/IP stack)? Thanks, -Sujith
[dpdk-dev] TCP/IP stack - options
Thanks Keith ! Your inputs are really helpful. I'll keep the contacts handy. Regards, -Sujith On 18/09/13 4:45 AM, "Wiles, Roger Keith" wrote: >Hi Sujith, > >Wind River also has a fully integrated TCP/IP stack with network >acceleration using DPKD with INP/AAE product. A few have ported lwIP to >DPDK, but these stacks are not fully integrated into the whole system >meaning the Linux host (at least I do not know of anyone that does). > >Wind River's INP product is a complete TCP/IP stack with many more >features and protocols backed by the largest embedded development company >in the world. We also have a very close relationship with Intel (as we >are wholly owned subsidiary of Intel) > >We have a patent pending socket layer acceleration design and many more >features. > >Please contact >steve.konish at windriver.com<mailto:steve.konish at windriver.com> or >Paul.Senyshyn at windriver.com<mailto:Paul.Senyshyn at windriver.com> for more >details.Keith Wiles, Principal Technologist for Networking member of the >CTO office, Wind River >direct 972.434.4136 mobile 940.213.5533 fax 000.000. >[Powering 30 Years of >Innovation]<http://www.windriver.com/announces/wr30/> > >On Sep 17, 2013, at 12:36 AM, Sujith Sankar (ssujith) >mailto:ssujith at cisco.com>> wrote: > >Hi Vincent, > >Sincere thanks to you for the email ! This is very helpful. >I think I'll go with Rump kernel stack to start with, and might think >about the other options later. > >Regards, >-Sujith > >On 17/09/13 2:01 AM, "Vincent JARDIN" >mailto:vincent.jardin at 6wind.com>> wrote: > >Hi Sujith, > >NetBSD/Rump is the only open source TCP/IP stack for DPDK. Some people >may have tried to port LwIP too. As far as we know, only 6WIND has a >robust and fully compliant stack which provides socket APIs to the >applications on top of the DPDK. I'd be pleased to get a list of options >for the DPDK too: > - Rump/NetBSD thanks to Antti > - maybe LwIP TBC > - 6WINDGate's fast path TCP/IP stack >and to list them on dpdk.org<http://dpdk.org>. > >My 2 cents, > Vincent > >Hi all, > >I'm new to DPDK and this group. > >In order to try out some of my applications on DPDK, I'd like to know a >little bit about the options that are there for protocol processing. >Could someone give info about the TCP/IP stacks that could be used with >DPDK libraries and applications? Quick googling gave a few names >(6Wind, >rump kernel tcp/ip stack, etc). But some wise words from the group >could >go a long way in helping me out. > >Thanks in advance ! >-Sujith > > > >
[dpdk-dev] TCP/IP stack - options
Thank you Gil. -Sujith On 17/09/13 6:39 PM, "Gil Hellmann" wrote: >Hi Sujith, > >To add to the respond given by Mr. Jardin, Wind River also has commercial >grade protocol stack that could be used with DPDK libraries and >application, it is part of Wind Rivers' INP (Intelligent Networking >Platform). > >Regards, >Gil Hellmann
[dpdk-dev] TCP/IP stack - options
Hi Vincent, Sincere thanks to you for the email ! This is very helpful. I think I'll go with Rump kernel stack to start with, and might think about the other options later. Regards, -Sujith On 17/09/13 2:01 AM, "Vincent JARDIN" wrote: >Hi Sujith, > >NetBSD/Rump is the only open source TCP/IP stack for DPDK. Some people >may have tried to port LwIP too. As far as we know, only 6WIND has a >robust and fully compliant stack which provides socket APIs to the >applications on top of the DPDK. I'd be pleased to get a list of options >for the DPDK too: > - Rump/NetBSD thanks to Antti > - maybe LwIP TBC > - 6WINDGate's fast path TCP/IP stack >and to list them on dpdk.org. > >My 2 cents, > Vincent > >> Hi all, >> >> I'm new to DPDK and this group. >> >> In order to try out some of my applications on DPDK, I'd like to know a >> little bit about the options that are there for protocol processing. >> Could someone give info about the TCP/IP stacks that could be used with >> DPDK libraries and applications? Quick googling gave a few names >>(6Wind, >> rump kernel tcp/ip stack, etc). But some wise words from the group >>could >> go a long way in helping me out. >> >> Thanks in advance ! >> -Sujith > >
[dpdk-dev] TCP/IP stack - options
Hi all, I'm new to DPDK and this group. In order to try out some of my applications on DPDK, I'd like to know a little bit about the options that are there for protocol processing. Could someone give info about the TCP/IP stacks that could be used with DPDK libraries and applications? Quick googling gave a few names (6Wind, rump kernel tcp/ip stack, etc). But some wise words from the group could go a long way in helping me out. Thanks in advance ! -Sujith
