[dpdk-dev] ethdev cleanup following hotplug changes
2015-07-17 18:31 GMT+09:00 Thomas Monjalon : > Hi Tetsuya, Hi Thomas, Sorry for late reply. I am out of office now, and will back to tomorrow. > > Any news about this comment in ethdev? > > * TODO: > * rte_eal_vdev_init() should return port_id, > * And rte_eth_dev_save() and rte_eth_dev_get_changed_port() > * should be removed. */ > > http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n618 So far, I don't have patch for that, also unfortunately, it may be difficult to have time in next few weeks. So I will submit the patch for DPDK-2.2. Will that fit your schedule? (Also, I will submit hotplug patch to support vfio devices for DPDK-2.2, if I can have time and anyone doesn't submit.) Regards, Tetsuya
[dpdk-dev] jumbo frame support for 82583V
Hi Klaus, > -Original Message- > From: Klaus Degner [mailto:kd at allegro-packets.com] > Sent: Monday, July 20, 2015 5:21 PM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: jumbo frame support for 82583V > > Hi Wenzhuo, > > Hi Klaus, > > > >> -Original Message- > >> From: Klaus Degner [mailto:kd at allegro-packets.com] > >> Sent: Friday, July 17, 2015 7:56 PM > >> To: Lu, Wenzhuo > >> Cc: dev at dpdk.org > >> Subject: jumbo frame support for 82583V > >> > >> Hi Wenzhuo, > >> > >> We are testing different Intel NICs for DPDK. We have tested the > >> master branch with the support for 82583V Intel chip. > >> It works very well except that we can only use up to 1518 bytes for > >> maximum packet capture. > >> We have debugged this and it is restricted in the initialization: > >> > >> http://dpdk.org/browse/dpdk/tree/drivers/net/e1000/em_ethdev.c#n855 > >> > >> Without DPDK, the linux driver support and mtu up to 9k and ark.intel > >> reports that this chip is jumbo frame capable: > >> > >> http://ark.intel.com/de/products/41676/Intel-82583V-Gigabit-Ethernet- > >> Controller > >> > >> Is there any specific reason why DPDK cannot use jumbo frames for this NIC > >> ? > >> > >> Thanks for help ! > >> > >> Klaus > > Sorry, I'm not sure about the history. > > According to the datasheet's update log, 82583v doesn't support jumbo frame > at first. > > I think the reason is the e1000 code is not updated after the datasheet > > said the > jumbo frame is supported. > > As I don?t have the NIC on hand, would you like to change the code and > > have a try. I mean just let " case e1000_82583" return 9K. Thanks. > > The DPDK jumbo frame send and receive works for 82583V. > We have tested it with 4x 85283V and the setup: > > Linux send --> DPDK receive --> DPDK send --> Linux receive > > We could send a 9k packet via this data path and have verified the content of > it. > I can generate a patch for DPDK if this is enough testing for you. Many thanks for verifying this. I think that's enough. If you'd like creating a patch for it, please move on:) > > Thanks, > > Klaus
[dpdk-dev] [PATCH v2 2/2] virtio: small cleanups
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, July 21, 2015 2:41 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: [PATCH v2 2/2] virtio: small cleanups
>
> Some minor cleanups.
> * pass constant to virtio_dev_queue_setup
> * fix message on rx_queue_setup
> * get rid of extra double spaces
>
> Signed-off-by: Stephen Hemminger
Acked-by: Changchun Ouyang
> ---
> drivers/net/virtio/virtio_ethdev.c | 7 +++
> drivers/net/virtio/virtio_ethdev.h | 2 +-
> drivers/net/virtio/virtio_rxtx.c | 2 +-
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index d460d89..465d3cd 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -254,7 +254,7 @@ virtio_dev_queue_release(struct virtqueue *vq) { int
> virtio_dev_queue_setup(struct rte_eth_dev *dev,
> int queue_type,
> uint16_t queue_idx,
> - uint16_t vtpci_queue_idx,
> + uint16_t vtpci_queue_idx,
> uint16_t nb_desc,
> unsigned int socket_id,
> struct virtqueue **pvq)
> @@ -264,7 +264,7 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
> uint16_t vq_size;
> int size;
> struct virtio_hw *hw = dev->data->dev_private;
> - struct virtqueue *vq = NULL;
> + struct virtqueue *vq = NULL;
>
> /* Write the virtqueue index to the Queue Select Field */
> VIRTIO_WRITE_REG_2(hw, VIRTIO_PCI_QUEUE_SEL,
> vtpci_queue_idx); @@ -413,13 +413,12 @@
> virtio_dev_cq_queue_setup(struct rte_eth_dev *dev, uint16_t
> vtpci_queue_idx,
> uint32_t socket_id)
> {
> struct virtqueue *vq;
> - uint16_t nb_desc = 0;
> int ret;
> struct virtio_hw *hw = dev->data->dev_private;
>
> PMD_INIT_FUNC_TRACE();
> ret = virtio_dev_queue_setup(dev, VTNET_CQ,
> VTNET_SQ_CQ_QUEUE_IDX,
> - vtpci_queue_idx, nb_desc, socket_id, &vq);
> + vtpci_queue_idx, 0, socket_id, &vq);
> if (ret < 0) {
> PMD_INIT_LOG(ERR, "control vq initialization failed");
> return ret;
> diff --git a/drivers/net/virtio/virtio_ethdev.h
> b/drivers/net/virtio/virtio_ethdev.h
> index 3858b00..9026d42 100644
> --- a/drivers/net/virtio/virtio_ethdev.h
> +++ b/drivers/net/virtio/virtio_ethdev.h
> @@ -79,7 +79,7 @@ void virtio_dev_rxtx_start(struct rte_eth_dev *dev);
> int virtio_dev_queue_setup(struct rte_eth_dev *dev,
> int queue_type,
> uint16_t queue_idx,
> - uint16_t vtpci_queue_idx,
> + uint16_t vtpci_queue_idx,
> uint16_t nb_desc,
> unsigned int socket_id,
> struct virtqueue **pvq);
> diff --git a/drivers/net/virtio/virtio_rxtx.c
> b/drivers/net/virtio/virtio_rxtx.c
> index 5388caa..c5b53bb 100644
> --- a/drivers/net/virtio/virtio_rxtx.c
> +++ b/drivers/net/virtio/virtio_rxtx.c
> @@ -390,7 +390,7 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
> ret = virtio_dev_queue_setup(dev, VTNET_RQ, queue_idx,
> vtpci_queue_idx,
> nb_desc, socket_id, &vq);
> if (ret < 0) {
> - PMD_INIT_LOG(ERR, "tvq initialization failed");
> + PMD_INIT_LOG(ERR, "rvq initialization failed");
> return ret;
> }
>
> --
> 2.1.4
[dpdk-dev] [PATCH v2 0/2] virtio: fixes for 2.1-rc1
> -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Tuesday, July 21, 2015 2:41 AM > To: Ouyang, Changchun > Cc: dev at dpdk.org; Stephen Hemminger > Subject: [PATCH v2 0/2] virtio: fixes for 2.1-rc1 I think v2 here should be v3, as you have already a v2. > > From: Stephen Hemminger > > This integrates my change and earlier change by Ouyang Changchun into one > fix. And second patch is minor stuff found while reviewing. > > Stephen Hemminger (2): > virtio: fix queue size and number of descriptors > virtio: small cleanups > > drivers/net/virtio/virtio_ethdev.c | 24 +++- > drivers/net/virtio/virtio_ethdev.h | 2 +- > drivers/net/virtio/virtio_rxtx.c | 2 +- > 3 files changed, 9 insertions(+), 19 deletions(-) > > -- > 2.1.4
[dpdk-dev] [PATCH v2 1/2] virtio: fix queue size and number of descriptors
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, July 21, 2015 2:41 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: [PATCH v2 1/2] virtio: fix queue size and number of descriptors
>
> The virtual queue ring size and the number of slots actually usable are
> separate parameters. In the most common environment (QEMU) the virtual
> queue ring size is 256, but some environments the ring maybe much larger.
>
> The ring size comes from the host and the driver must use the actual size
> passed.
>
> The number of descriptors can be either zero to use the whole available ring,
> or some value smaller. This is used to limit the number of mbufs allocated for
> the receive ring. If more descriptors are requested than available the size is
> silently truncated.
>
> Note: the ring size (from host) must be a power of two, but the number of
> descriptors used can be any size from 1 to the size of the virtual ring.
>
> Reported-by: Ouyang Changchun
> Signed-off-by: Stephen Hemminger
Basically ok for this change, so
Acked-by: Changchun Ouyang
> ---
> drivers/net/virtio/virtio_ethdev.c | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 9ca9bb2..d460d89 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -276,8 +276,6 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
>*/
> vq_size = VIRTIO_READ_REG_2(hw, VIRTIO_PCI_QUEUE_NUM);
> PMD_INIT_LOG(DEBUG, "vq_size: %d nb_desc:%d", vq_size,
> nb_desc);
> - if (nb_desc == 0)
> - nb_desc = vq_size;
> if (vq_size == 0) {
> PMD_INIT_LOG(ERR, "%s: virtqueue does not exist",
> __func__);
> return -EINVAL;
> @@ -288,16 +286,6 @@ int virtio_dev_queue_setup(struct rte_eth_dev
> *dev,
> return -EINVAL;
> }
>
> - if (nb_desc < vq_size) {
> - if (!rte_is_power_of_2(nb_desc)) {
> - PMD_INIT_LOG(ERR,
> - "nb_desc(%u) size is not powerof 2",
> - nb_desc);
> - return -EINVAL;
> - }
> - vq_size = nb_desc;
> - }
> -
> if (queue_type == VTNET_RQ) {
> snprintf(vq_name, sizeof(vq_name), "port%d_rvq%d",
> dev->data->port_id, queue_idx);
> @@ -325,7 +313,10 @@ int virtio_dev_queue_setup(struct rte_eth_dev
> *dev,
> vq->queue_id = queue_idx;
> vq->vq_queue_index = vtpci_queue_idx;
> vq->vq_nentries = vq_size;
> - vq->vq_free_cnt = vq_size;
> +
> + if (nb_desc == 0 || nb_desc > vq_size)
> + nb_desc = vq_size;
> + vq->vq_free_cnt = nb_desc;
>
> /*
>* Reserve a memzone for vring elements
> --
> 2.1.4
[dpdk-dev] [PATCH] virtio: fix the vq size issue
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, July 20, 2015 6:42 PM > To: Ouyang, Changchun > Cc: Xu, Qian Q; Stephen Hemminger; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] virtio: fix the vq size issue > > 2015-07-20 06:18, Ouyang, Changchun: > > Another thing burst into my thought. > > Can we think more about how to setup a mechanism to block those > patches which causes critical regression issue? > > Yes. Non-regression tests are needed. As it must be done with many > hardwares and many configurations, it must be a shared effort. > As a first step, you can run some automated tests by yourself and > *manually* raise errors on the mailing lists. When it will work well, we could > discuss about gathering test reports in a clean distributed way. > Note that this topic is already a work in progress by few people and a public > proposal should be done in few weeks. That's good. > > > I did review that patch before, but fail to realize it will break the basic > function of virtio PMD, it is my bad. > > (Can I send the nack to that patch even after it has been merged into > > dpdk.org?) > > After being approved and merged, a nack has no effect. > Having a revert approved is the good way. I have acked Stephen's new patch. > > > After that, we find that in our testing cycle, we spend time in > > investigating that and root the cause, and sent out the fixing patch on > > July 1. > Keeping virtio basic functionality broken more than 20 days is bad thing for > me. > > It wouldn't be so long if these 3 simple things were done: > - use a better title: "virtio: fix Rx from Qemu" instead of a not meaningful > "fix > the vq size issue" > - cc Stephen (I did it later) who did the original patch you wants to revert > - have an acked-by from Huawei Xie who commented the patch > > > If we can run a regression automation test with every patch set sent > > out to dpdk.org, and put those patches breaking any test cases Into > > failing-list and notify author, reviewer and maintainer, all those things > should be done before theirs being merged, then it will prevent from > merging the erroneous patch into mainline, and thus reduce most reverting > patch. > > As explained above, it is planned and you can start running you own local test > machine. But please do not spam the mailing list with automated mails from > these tests.
[dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats->ierrors
Hi, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maryam Tahhan > Sent: Monday, July 20, 2015 8:28 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats->ierrors > > Fixes: f6bf669b990004dc69231476d9fcf0b80574e568. Bug fix to remove > (rxnfgpc - hw_stats->gprc) which does not account for phy errors. > hw_stats->gprc is the Number of good (non-erred) Rx packets (from the > network) that pass L2 filtering and has a legal length as defined by > LongPacketEnable. While rxnfgpc is the Number of good (non-erred with legal > length) Rx packets (from the network) regardless of packet filtering and > receive > enablement. Thus hw_stats->gprc can be > rxnfgpc and this calculation should > be removed from the calculation of ierrors. > Validated with testpmd by sending packets to the interface without forwarding > enabled - packets should be dropped and the error counters incremented. > > v2: > - specified the commit that this bug fix fixes. > > Signed-off-by: Maryam Tahhan Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH v3 1/3] nic_uio: Fix to allow any device to be bound to nic_uio
On Mon, Jul 20, 2015 at 7:31 PM, Rahul Lakkireddy < rahul.lakkireddy at chelsio.com> wrote: > nic_uio requires the pci ids to be present in rte_pci_dev_ids.h in order to > bind the devices to nic_uio. However, it's better to remove this > whitelist of > pci ids, and instead rely on hw.nic_uio.bdfs kenv parameter to allow > binding > any device to nic_uio. > > Suggested-by: David Marchand > Signed-off-by: Rahul Lakkireddy > Signed-off-by: Kumar Sanghvi > --- > v3: > - Use checks for bus, slot, and function info instead of vendor and device > during nic_uio probe for better consistency. > Looks good to me. Acked-by: David Marchand Thanks Rahul. -- David Marchand
[dpdk-dev] [PATCH] fm10K: fix interrupt fault handling
Hi, Stephen, > -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Friday, July 17, 2015 8:33 AM > To: Qiu, Michael; Chen, Jing D > Cc: dev at dpdk.org; Stephen Hemminger > Subject: [PATCH] fm10K: fix interrupt fault handling > > The fm10k driver was reading the interrupt cause register but then > using the interrupt mask register defines to look at the bits. > The result is that if a fault happens, the driver would never clear > the fault and would get into an infinite cycle of interrupts. > > Note: I don't work for Intel or have the hardware manuals (probably > requires NDA anyway), but this looks logical and matches how the > known working Linux driver handles these bits. > > Signed-off-by: Stephen Hemminger Good catch! Thanks! Acked-by: Jing Chen
[dpdk-dev] [PATCH] fm10k: remove useless code
> -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Friday, July 17, 2015 6:05 AM > To: Chen, Jing D > Cc: dev at dpdk.org; Stephen Hemminger > Subject: [PATCH] fm10k: remove useless code > > The return in fm10k_dev_handle_fault has useless conditional > since it always returns 0 here. > > Signed-off-by: Stephen Hemminger Acked-by: Jing Chen
[dpdk-dev] [PATCH v2] fm10k: add missing newline to debug log
> -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Friday, July 17, 2015 5:07 AM > To: Chen, Jing D > Cc: dev at dpdk.org; Stephen Hemminger > Subject: [PATCH v2] fm10k: add missing newline to debug log > > If FM10K_DEBUG_DRIVER is enabled, then the log messages about > function entry are missing newline causing extremely long lines. > > Signed-off-by: Stephen Hemminger Acked-by : Jing Chen
[dpdk-dev] ethdev cleanup following hotplug changes
2015-07-21 08:49, Tetsuya Mukawa: > 2015-07-17 18:31 GMT+09:00 Thomas Monjalon : > > Any news about this comment in ethdev? > > > > * TODO: > > * rte_eal_vdev_init() should return port_id, > > * And rte_eth_dev_save() and rte_eth_dev_get_changed_port() > > * should be removed. */ > > > > http://dpdk.org/browse/dpdk/tree/lib/librte_ether/rte_ethdev.c#n618 > > So far, I don't have patch for that, also unfortunately, it may be > difficult to have time in next few weeks. > So I will submit the patch for DPDK-2.2. Will that fit your schedule? OK. There is no schedule, only some needs :) Knowing that you are not working on it currently, maybe someone else would like to do it. Thanks for the info. > (Also, I will submit hotplug patch to support vfio devices for > DPDK-2.2, if I can have time and anyone doesn't submit.) OK thanks
[dpdk-dev] Creation of ACL context with multiple tries
Hi Vartha, > Hi All, > Need your inputs on the following queries on ACL contexts. > > 1. Has anyone tried creating ACL context with multiple tries? > 2. The document/code mentioned that we can have the maximum of 8 > tries(RTE_ACL_MAX_TRIES) per ACL context. > What is the use case for having more than single trie? User can't directly control number of tries per context and/or contents of each trie at build time. It is decided by build time by librte_acl internal logic and depends from the rule set and build parameters. Please refer to: http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html Section 23.1.2. RT memory size limit. > 3. If we can create ACL context using multiple tries, then is it possible to > have trie per category in ACL context? > Meaning I want to create a single ACL context(that had both ipv4 and ipv6 > rules) which have 2 tries with one for ipv4 rules and > another one for ipv6 rules. No, that's no possible with current implementation. Konstantin > Thanks in Advance. > > Thanks > Vartha
[dpdk-dev] [PATCH v3 0/3] cxgbe: Fix compilation and enable FreeBSD support for CXGBE PMD
On Mon, Jul 20, 2015 at 11:01:34PM +0530, Rahul Lakkireddy wrote: > This series of patches fix compilation and enable CXGBE poll mode driver for > FreeBSD. The first patch fixes a limitation of nic_uio that only binds to > devices present in rte_pci_dev_ids.h. The second patch does the actual > compilation fix and enabling of CXGBE PMD for FreeBSD. The last patch updates > cxgbe documentation to reflect the FreeBSD support for CXGBE PMD. > > v3: > - Use checks for bus, slot, and function info instead of vendor and device > during nic_uio probe for better consistency. > > v2: > - Replace "Intel(R) DPDK" with just "DPDK" in device description for nic_uio. > > Rahul Lakkireddy (3): > nic_uio: Fix to allow any device to be bound to nic_uio > cxgbe: Enable and fix FreeBSD compilation for CXGBE PMD > doc: Update documentation to reflect FreeBSD support for CXGBE PMD > Compilation testing with the patches on my FreeBSD system is all ok, and unbinding of Intel 10G NICs works ok as before for me. Thanks for the patches and the new FreeBSD hardware support! Series Acked-by: Bruce Richardson
[dpdk-dev] Does PCI hotplug work with IVSHMEM?
Dear all, we're adding dynamically an IVSHMEM device on a VM that is already running, but apparently this is not visible in DPDK, while it is correctly recognized by the Guest OS. This is the list of steps we execute: 1) Launch a new Guest VM with Qemu 2) Create a new IVSHMEM metadata file in the Host 3) Map that file as a new IVSHMEM device in the Guest For this step, we use the "device_add" command from Qemu: (qemu) device_add ivshmem,size=2048M,shm=fd:/dev/hugepages /rtemap_0:0x0:0x4000:/dev/zero:0x0:0x3fffc000:/var/run /.dpdk_ivshmem_metadata_vm_1:0x0:0x4000 4) List the available PCI devices in the Guest with "lspci": $ sudo lspci 00:04.0 RAM memory: Red Hat, Inc Virtio Inter-VM shared memory ==> hence, the Guest OS correctly recognizes the new device 5) Lauch a DPDK simple application such as 'helloworld' in the Guest: $ sudo ./build/helloworld -c 0x1 -n 4 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 2 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Searching for IVSHMEM devices... EAL: No IVSHMEM configuration found! EAL: Setting up memory... ==> Hence, the DPDK app in the Guest OS doesn't recognize the new device. An additional observations that may be important here. If we reboot the Guest and re-lauch the same DPDK as before, the IVSHMEM is correclty detected by the DPDK app: $ sudo reboot $ sudo ./build/helloworld -c 0x1 -n 4 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 2 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Searching for IVSHMEM devices... EAL: Parsing metadata for "vm_1" EAL: Found IVSHMEM device 00:04.0 EAL: Memory segment mapped: 0x7f8b40d8c000 (len 3937000) at offset 0xd8c000 EAL: IVSHMEM segment found, size: 0x3936ec0 EAL: Setting up memory... Finally, this is what the DPDK programming guide says about IVSHMEM: --- http://dpdk.org/doc/guides/prog_guide/ivshmem_lib.html Currently, there is no hot plug support for QEMU IVSHMEM devices, so one cannot add additional memory to an IVSHMEM device once it has been created. Therefore, the correct sequence to run an IVSHMEM application is to run host application first, obtain the command lines for each IVSHMEM device and then run all QEMU instances with guest applications afterwards. --- To our understanding, IVSHMEM HotPlug is supported, but we cannot resize dynamically the memory. Is that correct? fulvio
[dpdk-dev] [PATCH] DPDK fails to build into one single library ("CONFIG_RTE_BUILD_COMBINE_LIBS=y").
The reason why I took into account as a solution the commenting of that line is
that LIBRTE_EAL already has rte_malloc integrated.
So, I'm not sure why the line is needed ...
/Alin
-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
Sent: Monday, July 20, 2015 7:15 PM
To: Rauta, Alin
Cc: dev at dpdk.org; Varlese, Marco
Subject: Re: [dpdk-dev] [PATCH] DPDK fails to build into one single library
("CONFIG_RTE_BUILD_COMBINE_LIBS=y").
2015-07-20 18:04, Rauta, Alin:
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -33,7 +33,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
>
> DIRS-y += librte_compat
> DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
> -DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_malloc
I feel it's not the right fix :)
>From now, I'll test combine lib build.
Thanks for reporting
[dpdk-dev] [PATCH] DPDK fails to build into one single library ("CONFIG_RTE_BUILD_COMBINE_LIBS=y").
On 21/07/2015 10:49, Rauta, Alin wrote:
> The reason why I took into account as a solution the commenting of that line
> is that LIBRTE_EAL already has rte_malloc integrated.
> So, I'm not sure why the line is needed ...
> /Alin
That line is needed so when we create shared libs it creates a dummy lib
so we don't brake apps that expect a librte_malloc.so.
I'm working on a fix, will post it soon.
Sergio
>
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, July 20, 2015 7:15 PM
> To: Rauta, Alin
> Cc: dev at dpdk.org; Varlese, Marco
> Subject: Re: [dpdk-dev] [PATCH] DPDK fails to build into one single library
> ("CONFIG_RTE_BUILD_COMBINE_LIBS=y").
>
> 2015-07-20 18:04, Rauta, Alin:
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@ -33,7 +33,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
>>
>> DIRS-y += librte_compat
>> DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
>> -DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_malloc
> I feel it's not the right fix :)
>
> From now, I'll test combine lib build.
> Thanks for reporting
[dpdk-dev] [PATCH] malloc: fix combined lib build
Malloc was moved to the EAL and dummy malloc library was left
to not brake apps that had a librte_malloc.so dependency.
Note that the dummy library will be removed in the next release.
When building a combined library, all objects are copied to the same
directory before creating the library itself.
There a couple of issues:
- CONFIG_RTE_LIBRTE_MALLOC is not a valid option anymore resulting
in wrong syntax and a compilation failure. Fix it by replacing it
with CONFIG_RTE_LIBRTE_EAL.
- As we kept a dummy library, there are now two objects with the
same name. This means that the proper rte_malloc.o object in eal gets
overwritten by an empty rte_malloc.o object from the dummy malloc lib.
Fix it by changing the name of rte_malloc.o object in the dummy
library.
Fixes: 2f9d47013e4dbb738 ("mem: move librte_malloc to eal/common")
Reported-by: Alin Rauta
Signed-off-by: Sergio Gonzalez Monroy
---
lib/librte_malloc/Makefile | 4 ++--
lib/librte_malloc/rte_malloc.c | 34 --
lib/librte_malloc/rte_malloc_empty.c | 34 ++
3 files changed, 36 insertions(+), 36 deletions(-)
delete mode 100644 lib/librte_malloc/rte_malloc.c
create mode 100644 lib/librte_malloc/rte_malloc_empty.c
diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile
index 32d86b9..9558f3d 100644
--- a/lib/librte_malloc/Makefile
+++ b/lib/librte_malloc/Makefile
@@ -40,9 +40,9 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
EXPORT_MAP := rte_malloc_version.map
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_MALLOC) := rte_malloc.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL) := rte_malloc_empty.c
# this lib needs eal
-DEPDIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_EAL) += lib/librte_eal
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_malloc/rte_malloc.c b/lib/librte_malloc/rte_malloc.c
deleted file mode 100644
index 4b9dc7f..000
--- a/lib/librte_malloc/rte_malloc.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*-
- * BSD LICENSE
- *
- * Copyright(c) 2010-2014 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.
- */
-
-/* Empty file to be able to create a dummy library for deprecation policy */
diff --git a/lib/librte_malloc/rte_malloc_empty.c
b/lib/librte_malloc/rte_malloc_empty.c
new file mode 100644
index 000..4b9dc7f
--- /dev/null
+++ b/lib/librte_malloc/rte_malloc_empty.c
@@ -0,0 +1,34 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 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
[dpdk-dev] [PATCH v5 1/3] bonding: add support for PCI Port Hotplug
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Saturday, July 18, 2015 9:40 PM > To: Iremonger, Bernard > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 1/3] bonding: add support for PCI Port > Hotplug > > 2015-07-15 16:32, Bernard Iremonger: > > This patch depends on the Port Hotplug Framework. > > It implements the rte_dev_uninit_t() function for the link bonding pmd. > > > > Signed-off-by: Bernard Iremonger > > --- > > drivers/net/bonding/rte_eth_bond.h | 13 - > > drivers/net/bonding/rte_eth_bond_api.c | 78 +++- > -- > > drivers/net/bonding/rte_eth_bond_pmd.c | 23 - > > drivers/net/bonding/rte_eth_bond_private.h | 7 ++- > [...] > > --- a/drivers/net/bonding/rte_eth_bond.h > > +++ b/drivers/net/bonding/rte_eth_bond.h > > /** > > + * Free a bonded rte_eth_dev device > > + * > > + * @param name Name of the link bonding device. > > + * > > + * @return > > + * 0 on success, negative value otherwise > > + */ > > +int > > +rte_eth_bond_free(const char *name); > > Why it is not exported in .map? This is an oversight, I will set a v6 patch set. Regards, Bernard.
[dpdk-dev] [PATCH] malloc: fix combined lib build
Malloc was moved to the EAL and dummy malloc library was left
to not brake apps that had a librte_malloc.so dependency.
Note that the dummy library will be removed in the next release.
When building a combined library, all objects are copied to the same
directory before creating the library itself.
There a couple of issues:
- CONFIG_RTE_LIBRTE_MALLOC is not a valid option anymore resulting
in wrong syntax and a compilation failure. Fix it by replacing it
with CONFIG_RTE_LIBRTE_EAL.
- As we kept a dummy library, there are now two objects with the
same name. This means that the proper rte_malloc.o object in eal gets
overwritten by an empty rte_malloc.o object from the dummy malloc lib.
Fix it by changing the name of rte_malloc.o object in the dummy
library.
Fixes: 2f9d47013e4dbb738 ("mem: move librte_malloc to eal/common")
Reported-by: Alin Rauta
Signed-off-by: Sergio Gonzalez Monroy
---
lib/librte_malloc/Makefile | 4 ++--
lib/librte_malloc/rte_malloc.c | 34 --
lib/librte_malloc/rte_malloc_empty.c | 34 ++
3 files changed, 36 insertions(+), 36 deletions(-)
delete mode 100644 lib/librte_malloc/rte_malloc.c
create mode 100644 lib/librte_malloc/rte_malloc_empty.c
diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile
index 32d86b9..9558f3d 100644
--- a/lib/librte_malloc/Makefile
+++ b/lib/librte_malloc/Makefile
@@ -40,9 +40,9 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
EXPORT_MAP := rte_malloc_version.map
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_MALLOC) := rte_malloc.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL) := rte_malloc_empty.c
# this lib needs eal
-DEPDIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_EAL) += lib/librte_eal
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_malloc/rte_malloc.c b/lib/librte_malloc/rte_malloc.c
deleted file mode 100644
index 4b9dc7f..000
--- a/lib/librte_malloc/rte_malloc.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*-
- * BSD LICENSE
- *
- * Copyright(c) 2010-2014 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.
- */
-
-/* Empty file to be able to create a dummy library for deprecation policy */
diff --git a/lib/librte_malloc/rte_malloc_empty.c
b/lib/librte_malloc/rte_malloc_empty.c
new file mode 100644
index 000..4b9dc7f
--- /dev/null
+++ b/lib/librte_malloc/rte_malloc_empty.c
@@ -0,0 +1,34 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 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
[dpdk-dev] [PATCH] malloc: fix combined lib build
On 21/07/2015 11:18, Sergio Gonzalez Monroy wrote:
> Malloc was moved to the EAL and dummy malloc library was left
> to not brake apps that had a librte_malloc.so dependency.
> Note that the dummy library will be removed in the next release.
>
> When building a combined library, all objects are copied to the same
> directory before creating the library itself.
>
> There a couple of issues:
> - CONFIG_RTE_LIBRTE_MALLOC is not a valid option anymore resulting
> in wrong syntax and a compilation failure. Fix it by replacing it
> with CONFIG_RTE_LIBRTE_EAL.
> - As we kept a dummy library, there are now two objects with the
> same name. This means that the proper rte_malloc.o object in eal gets
> overwritten by an empty rte_malloc.o object from the dummy malloc lib.
> Fix it by changing the name of rte_malloc.o object in the dummy
> library.
>
> Fixes: 2f9d47013e4dbb738 ("mem: move librte_malloc to eal/common")
>
> Reported-by: Alin Rauta
> Signed-off-by: Sergio Gonzalez Monroy
> ---
>
I sent the same patch twice by accident, please ignore the second patch.
Sergio
[dpdk-dev] [PATCH v2] malloc: fix combined lib build
Malloc was moved to the EAL and dummy malloc library was left
to not break apps that had a librte_malloc.so dependency.
Note that the dummy library will be removed in the next release.
When building a combined library, all objects are copied to the same
directory before creating the library itself.
There are a few issues:
- CONFIG_RTE_LIBRTE_MALLOC is not a valid option anymore resulting
in wrong syntax and a compilation failure. Fix it by replacing it
with CONFIG_RTE_LIBRTE_EAL.
- As we kept a dummy library, there are now two objects with the
same name. This means that the proper rte_malloc.o object in eal gets
overwritten by an empty rte_malloc.o object from the dummy malloc lib.
Fix it by changing the name of rte_malloc.o object in the dummy
library.
- Update the copyright year.
Fixes: 2f9d47013e4dbb738 ("mem: move librte_malloc to eal/common")
Reported-by: Alin Rauta
Signed-off-by: Sergio Gonzalez Monroy
---
v2:
- Fix spelling error (brake -> break)
- Update copyright year of dummy file
lib/librte_malloc/Makefile | 4 ++--
lib/librte_malloc/rte_malloc.c | 34 --
lib/librte_malloc/rte_malloc_empty.c | 34 ++
3 files changed, 36 insertions(+), 36 deletions(-)
delete mode 100644 lib/librte_malloc/rte_malloc.c
create mode 100644 lib/librte_malloc/rte_malloc_empty.c
diff --git a/lib/librte_malloc/Makefile b/lib/librte_malloc/Makefile
index 32d86b9..9558f3d 100644
--- a/lib/librte_malloc/Makefile
+++ b/lib/librte_malloc/Makefile
@@ -40,9 +40,9 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
EXPORT_MAP := rte_malloc_version.map
# all source are stored in SRCS-y
-SRCS-$(CONFIG_RTE_LIBRTE_MALLOC) := rte_malloc.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL) := rte_malloc_empty.c
# this lib needs eal
-DEPDIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_EAL) += lib/librte_eal
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_malloc/rte_malloc.c b/lib/librte_malloc/rte_malloc.c
deleted file mode 100644
index 4b9dc7f..000
--- a/lib/librte_malloc/rte_malloc.c
+++ /dev/null
@@ -1,34 +0,0 @@
-/*-
- * BSD LICENSE
- *
- * Copyright(c) 2010-2014 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.
- */
-
-/* Empty file to be able to create a dummy library for deprecation policy */
diff --git a/lib/librte_malloc/rte_malloc_empty.c
b/lib/librte_malloc/rte_malloc_empty.c
new file mode 100644
index 000..4892a61
--- /dev/null
+++ b/lib/librte_malloc/rte_malloc_empty.c
@@ -0,0 +1,34 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2015 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
[dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats->ierrors
Tested-by: Marvin Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Lu, Wenzhuo > Sent: Tuesday, July 21, 2015 1:41 PM > To: Tahhan, Maryam; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats- > >ierrors > > Hi, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maryam Tahhan > > Sent: Monday, July 20, 2015 8:28 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v2 1/1] ixgbe: Fix phy errors in stats- > >ierrors > > > > Fixes: f6bf669b990004dc69231476d9fcf0b80574e568. Bug fix to remove > > (rxnfgpc - hw_stats->gprc) which does not account for phy errors. > > hw_stats->gprc is the Number of good (non-erred) Rx packets (from the > > network) that pass L2 filtering and has a legal length as defined by > > LongPacketEnable. While rxnfgpc is the Number of good (non-erred with > legal > > length) Rx packets (from the network) regardless of packet filtering and > receive > > enablement. Thus hw_stats->gprc can be > rxnfgpc and this calculation > should > > be removed from the calculation of ierrors. > > Validated with testpmd by sending packets to the interface without > forwarding > > enabled - packets should be dropped and the error counters incremented. > > > > v2: > > - specified the commit that this bug fix fixes. > > > > Signed-off-by: Maryam Tahhan > Acked-by: Wenzhuo Lu
[dpdk-dev] Non-working TX IP checksum offload
Hi Andriy, thank you, that solved it. Regards, Angela Andriy Berestovskyy wrote on 07/17/2015 04:37:45 PM: > From: Andriy Berestovskyy > To: Angela Czubak/Poland/Contr/IBM at IBMPL, > Cc: dev at dpdk.org > Date: 07/17/2015 04:38 PM > Subject: Re: [dpdk-dev] Non-working TX IP checksum offload > > Cze?? Angela, > Make sure your NIC is configured properly as described in this thread: > http://dpdk.org/ml/archives/dev/2015-May/018096.html > > Andriy > > On Fri, Jul 17, 2015 at 4:23 PM, Angela Czubak wrote: > > Hi, > > > > I have some difficulties using ip checksum tx offload capabilities - I > > think I set everything as advised by the API documentation, but > > unfortunately the packet leaves the interface with its ip checksum still > > being zero (it reaches its destination). > > > > What I do is: > > buffer->ol_flags |= PKT_TX_IP_CKSUM|PKT_TX_IPV4; > > ip_header->hdr_checksum = 0; > > buffer->l3_len = sizeof(struct ipv4_hdr); > > buffer->l2_len = sizeof(struct ether_hdr); > > > > In L4 there's UDP, which checksum is zeroed if that matters. > > > > Is there something I am missing? The NIC is Intel Corporation Ethernet > > Controller X710 for 10GbE SFP+ (rev 01). > > > > What is more, is there any particular reason for assuming in > > i40e_xmit_pkts that offloading checksums is unlikely (I mean the line no > > 1307 "if (unlikely(ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK))" at > > dpdk-2.0.0/lib/librte_pmd_i40e/i40e_rxtx.c)? > > > > Regards, > > Angela > > > > -- > Andriy Berestovskyy >
[dpdk-dev] [PATCH 1/4] doc: rename ABI chapter to deprecation
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Sunday, July 19, 2015 11:52 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/4] doc: rename ABI chapter to deprecation
>
> This chapter is for ABI and API. That's why a renaming is required.
>
> Remove also the examples which are now in the referenced guidelines.
>
> Signed-off-by: Thomas Monjalon
> ---
> MAINTAINERS | 2 +-
> doc/guides/rel_notes/{abi.rst => deprecation.rst} | 16 +---
> doc/guides/rel_notes/index.rst| 2 +-
> 3 files changed, 7 insertions(+), 13 deletions(-)
> rename doc/guides/rel_notes/{abi.rst => deprecation.rst} (51%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2a32659..6531900 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -60,7 +60,7 @@ F: doc/guides/prog_guide/ext_app_lib_make_help.rst
> ABI versioning
> M: Neil Horman
> F: lib/librte_compat/
> -F: doc/guides/rel_notes/abi.rst
> +F: doc/guides/rel_notes/deprecation.rst
> F: scripts/validate-abi.sh
>
>
> diff --git a/doc/guides/rel_notes/abi.rst
> b/doc/guides/rel_notes/deprecation.rst
> similarity index 51%
> rename from doc/guides/rel_notes/abi.rst
> rename to doc/guides/rel_notes/deprecation.rst
> index 7a08830..eef01f1 100644
> --- a/doc/guides/rel_notes/abi.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -1,17 +1,11 @@
> -ABI policy
> -==
> +Deprecation
> +===
>
> See the :doc:`guidelines document for details of the ABI policy
> `.
> -ABI deprecation notices are to be posted here.
> +API and ABI deprecation notices are to be posted here.
>
> -
> -Examples of Deprecation Notices
>
> -
> -* The Macro #RTE_FOO is deprecated and will be removed with version 2.0,
> to be replaced with the inline function rte_bar()
> -* The function rte_mbuf_grok has been updated to include new parameter
> in version 2.0. Backwards compatibility will be maintained for this function
> until the release of version 2.1
> -* The members struct foo have been reorganized in release 2.0. Existing
> binary applications will have backwards compatibility in release 2.0, while
> newly built binaries will need to reference new structure variant struct foo2.
> Compatibility will be removed in release 2.2, and all applications will
> require
> updating and rebuilding to the new structure at that time, which will be
> renamed to the original struct foo.
> -* Significant ABI changes are planned for the librte_dostuff library. The
> upcoming release 2.0 will not contain these changes, but release 2.1 will, and
> no backwards compatibility is planned due to the invasive nature of these
> changes. Binaries using this library built prior to version 2.1 will require
> updating and recompilation.
> +Help to update from a previous release is provided in
> +:doc:`another section `.
>
>
> Deprecation Notices
> diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
> index d790783..9d66cd8 100644
> --- a/doc/guides/rel_notes/index.rst
> +++ b/doc/guides/rel_notes/index.rst
> @@ -48,5 +48,5 @@ Contents
> updating_apps
> known_issues
> resolved_issues
> -abi
> +deprecation
> faq
> --
> 2.4.2
Hi Thomas,
There are some pending doc patches on ABI changes that have been sent and
ack-ed prior to this change.
Due to this change, they cannot be applied cleanly anymore. Are you OK to
integrate them with the small local change required from your side?
Thanks,
Cristian
[dpdk-dev] [PATCH 1/4] doc: rename ABI chapter to deprecation
2015-07-21 13:20, Dumitrescu, Cristian: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > --- a/doc/guides/rel_notes/abi.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > There are some pending doc patches on ABI changes that have been sent and > ack-ed prior to this change. > > Due to this change, they cannot be applied cleanly anymore. > Are you OK to integrate them with the small local change required from your > side? Yes it is a basic merge issue that is easily managed locally. Though, it would be nice to have at least 3 acks on these patches, as specified in the ABI policy.
[dpdk-dev] [PATCH] hash: move field hash_func_init_val in rte_hash struct
In order to keep the ABI consistent with the old hash library,
hash_func_init_val field has been moved, so it remains
at the same offset as previously, since hash_func and
hash_func_init_val are fields accesed by the public function
rte_hash_hash and must keep the same offset as older versions.
Signed-off-by: Pablo de Lara
---
lib/librte_hash/rte_cuckoo_hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index dec18ce..5cf4af6 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -105,8 +105,8 @@ struct rte_hash {
uint32_t num_buckets; /**< Number of buckets in table. */
uint32_t key_len; /**< Length of hash key. */
rte_hash_function hash_func;/**< Function used to calculate hash. */
- rte_hash_cmp_eq_t rte_hash_cmp_eq; /**< Function used to compare keys.
*/
uint32_t hash_func_init_val;/**< Init value used by hash_func. */
+ rte_hash_cmp_eq_t rte_hash_cmp_eq; /**< Function used to compare keys.
*/
uint32_t bucket_bitmask;/**< Bitmask for getting bucket index
from hash signature. */
uint32_t key_entry_size; /**< Size of each key entry. */
--
2.4.2
[dpdk-dev] [PATCH 1/1] ip_pipeline: fixed parsing cpu cores
This patch fixes parsing value of core variable in pipeline config.
Before not every combination of cores (c), sockets (s) and
hyperthreading (h) was parsed correctly.
Signed-off-by: Maciej Gajdzica
---
examples/ip_pipeline/config_parse.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/examples/ip_pipeline/config_parse.c
b/examples/ip_pipeline/config_parse.c
index 361bf8a..c9b78f9 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -386,14 +386,14 @@ parse_pipeline_core(uint32_t *socket,
switch (type) {
case 's':
case 'S':
- if (s_parsed)
+ if (s_parsed || c_parsed || h_parsed)
return -EINVAL;
s_parsed = 1;
next++;
break;
case 'c':
case 'C':
- if (c_parsed)
+ if (c_parsed || h_parsed)
return -EINVAL;
c_parsed = 1;
next++;
@@ -423,7 +423,10 @@ parse_pipeline_core(uint32_t *socket,
num[num_len] = *next;
}
- if (num_len == 0 && type != 'h')
+ if (num_len == 0 && type != 'h' && type != 'H')
+ return -EINVAL;
+
+ if (num_len != 0 && (type == 'h' || type == 'H'))
return -EINVAL;
num[num_len] = '\0';
@@ -438,9 +441,6 @@ parse_pipeline_core(uint32_t *socket,
case 'c':
case 'C':
c = val;
- if (type == 'C' && *next != '\0')
- return -EINVAL;
-
break;
case 'h':
case 'H':
--
1.7.9.5
[dpdk-dev] ixgbe_recv_scattered_pkts_vec split_flags question
Hi,
I have a question regarding split_flags in this question. It's defined
as an array of 1 byte unsigned ints:
uint8_t split_flags[RTE_IXGBE_VPMD_RX_BURST] = {0};
RTE_IXGBE_VPMD_RX_BURST is 32, so it will be 32 bytes. Then we cast it
into a pointer for 4 byte values, and check the first 4 elements of that
array
const uint32_t *split_fl32 = (uint32_t *)split_flags;
if (rxq->pkt_first_seg == NULL &&
split_fl32[0] == 0 && split_fl32[1] == 0 &&
split_fl32[2] == 0 && split_fl32[3] == 0)
So we only check the first half of this 32 byte array. But
_recv_raw_pkts_vec() seems to use the whole array. Is this a bug or a
feature? Or am I mistaken in the math somewhere?
Regards,
Zoltan Kiss
[dpdk-dev] [PATCH v6 2/3] test-pmd: modified testpmd for link_bonding
When the bonded port is started it also starts the slave port,
but the slave port status is not set. A slave_flag has been
added to struct rte_port to resolve this issue.
Signed-off-by: Bernard Iremonger
---
app/test-pmd/cmdline.c | 4 +++-
app/test-pmd/testpmd.c | 22 --
app/test-pmd/testpmd.h | 7 +--
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 8ab4687..5e24319 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* Copyright(c) 2014 6WIND S.A.
* All rights reserved.
*
@@ -4019,6 +4019,7 @@ static void cmd_add_bonding_slave_parsed(void
*parsed_result,
return;
}
init_port_config();
+ set_port_slave_flag(slave_port_id);
}
cmdline_parse_token_string_t cmd_addbonding_slave_add =
@@ -4075,6 +4076,7 @@ static void cmd_remove_bonding_slave_parsed(void
*parsed_result,
return;
}
init_port_config();
+ clear_port_slave_flag(slave_port_id);
}
cmdline_parse_token_string_t cmd_removebonding_slave_remove =
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 4769533..4bcece6 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1202,7 +1202,8 @@ all_ports_started(void)
FOREACH_PORT(pi, ports) {
port = &ports[pi];
/* Check if there is a port which is not started */
- if (port->port_status != RTE_PORT_STARTED)
+ if ((port->port_status != RTE_PORT_STARTED) &&
+ (port->slave_flag == 0))
return 0;
}
@@ -1218,7 +1219,8 @@ all_ports_stopped(void)
FOREACH_PORT(pi, ports) {
port = &ports[pi];
- if (port->port_status != RTE_PORT_STOPPED)
+ if ((port->port_status != RTE_PORT_STOPPED) &&
+ (port->slave_flag == 0))
return 0;
}
@@ -1808,6 +1810,22 @@ init_port_config(void)
}
}
+void set_port_slave_flag(portid_t slave_pid)
+{
+ struct rte_port *port;
+
+ port = &ports[slave_pid];
+ port->slave_flag = 1;
+}
+
+void clear_port_slave_flag(portid_t slave_pid)
+{
+ struct rte_port *port;
+
+ port = &ports[slave_pid];
+ port->slave_flag = 0;
+}
+
const uint16_t vlan_tags[] = {
0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15,
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index e91e077..8b2219a 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -162,11 +162,12 @@ struct rte_port {
uint8_t need_reconfig; /**< need reconfiguring port or
not */
uint8_t need_reconfig_queues; /**< need reconfiguring
queues or not */
uint8_t rss_flag; /**< enable rss or not */
- uint8_t dcb_flag; /**< enable dcb */
+ uint8_t dcb_flag; /**< enable dcb */
struct rte_eth_rxconf rx_conf;/**< rx configuration */
struct rte_eth_txconf tx_conf;/**< tx configuration */
struct ether_addr *mc_addr_pool; /**< pool of multicast addrs */
uint32_tmc_addr_nb; /**< nb. of addr. in mc_addr_pool */
+ uint8_t slave_flag; /**< bonding slave port */
};
extern portid_t __rte_unused
@@ -534,6 +535,8 @@ void stop_packet_forwarding(void);
void dev_set_link_up(portid_t pid);
void dev_set_link_down(portid_t pid);
void init_port_config(void);
+void set_port_slave_flag(portid_t slave_pid);
+void clear_port_slave_flag(portid_t slave_pid);
int init_port_dcb_config(portid_t pid,struct dcb_config *dcb_conf);
int start_port(portid_t pid);
void stop_port(portid_t pid);
--
1.9.1
[dpdk-dev] [PATCH v6 3/3] bonding: free queue memory in stop function
add function bond_ethdev_free_queues() and call from the bond_ethdev_stop()
function.
Signed-off-by: Bernard Iremonger
---
drivers/net/bonding/rte_eth_bond_pmd.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index cad8f3c..2221197 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -1512,6 +1512,24 @@ bond_ethdev_start(struct rte_eth_dev *eth_dev)
return 0;
}
+static void
+bond_ethdev_free_queues(struct rte_eth_dev *dev)
+{
+ uint8_t i;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ rte_free(dev->data->rx_queues[i]);
+ dev->data->rx_queues[i] = NULL;
+ }
+ dev->data->nb_rx_queues = 0;
+
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ rte_free(dev->data->tx_queues[i]);
+ dev->data->tx_queues[i] = NULL;
+ }
+ dev->data->nb_tx_queues = 0;
+}
+
void
bond_ethdev_stop(struct rte_eth_dev *eth_dev)
{
@@ -1550,6 +1568,8 @@ bond_ethdev_stop(struct rte_eth_dev *eth_dev)
eth_dev->data->dev_link.link_status = 0;
eth_dev->data->dev_started = 0;
+
+ bond_ethdev_free_queues(eth_dev);
}
static void
--
1.9.1
[dpdk-dev] [PATCH v6 0/3] bonding PCI Port Hotplug
Changes in V6: Rebase. add rte_eth_bond_free() to rte_eth_bond_version.map Changes in V5: Rebase. Refactor initialisation of static structures. Changes in V4: Rebase to latest code. Move freeing of queue memory from uninit() function to close() function. Changes in V3: Rebase to latest code. Modified testpmd to handle attach/detach of bonding pmd. Changes in V2: Rebased to use drivers/net/bonding dirctory Free rx and tx queues in uninit() function. Bernard Iremonger (3): bonding: add support for PCI Port Hotplug test-pmd: modified testpmd for link_bonding bonding: free queue memory in stop function app/test-pmd/cmdline.c | 4 +- app/test-pmd/testpmd.c | 22 +++- app/test-pmd/testpmd.h | 7 ++- drivers/net/bonding/rte_eth_bond.h | 13 - drivers/net/bonding/rte_eth_bond_api.c | 78 ++-- drivers/net/bonding/rte_eth_bond_pmd.c | 41 ++- drivers/net/bonding/rte_eth_bond_private.h | 7 ++- drivers/net/bonding/rte_eth_bond_version.map | 1 + 8 files changed, 137 insertions(+), 36 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v6 1/3] bonding: add support for PCI Port Hotplug
This patch depends on the Port Hotplug Framework.
It implements the rte_dev_uninit_t() function for the link bonding pmd.
Signed-off-by: Bernard Iremonger
---
drivers/net/bonding/rte_eth_bond.h | 13 -
drivers/net/bonding/rte_eth_bond_api.c | 78 ++--
drivers/net/bonding/rte_eth_bond_pmd.c | 23 +++-
drivers/net/bonding/rte_eth_bond_private.h | 7 ++-
drivers/net/bonding/rte_eth_bond_version.map | 1 +
5 files changed, 90 insertions(+), 32 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond.h
b/drivers/net/bonding/rte_eth_bond.h
index d688fc3..8efbf07 100644
--- a/drivers/net/bonding/rte_eth_bond.h
+++ b/drivers/net/bonding/rte_eth_bond.h
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -131,6 +131,17 @@ int
rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id);
/**
+ * Free a bonded rte_eth_dev device
+ *
+ * @param name Name of the link bonding device.
+ *
+ * @return
+ * 0 on success, negative value otherwise
+ */
+int
+rte_eth_bond_free(const char *name);
+
+/**
* Add a rte_eth_dev device as a slave to the bonded device
*
* @param bonded_port_id Port ID of bonded device.
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index f602658..61ae7ef 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -163,7 +163,22 @@ number_of_sockets(void)
return ++sockets;
}
-const char *pmd_bond_driver_name = "Link Bonding PMD";
+const char pmd_bond_driver_name[] = "rte_bond_pmd";
+
+static struct rte_pci_id pci_id_table = {
+ .device_id = PCI_ANY_ID,
+ .subsystem_device_id = PCI_ANY_ID,
+ .vendor_id = PCI_ANY_ID,
+ .subsystem_vendor_id = PCI_ANY_ID,
+};
+
+static struct eth_driver rte_bond_pmd = {
+ .pci_drv = {
+ .name = pmd_bond_driver_name,
+ .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
+ .id_table = &pci_id_table,
+ },
+};
int
rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id)
@@ -171,9 +186,8 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
struct rte_pci_device *pci_dev = NULL;
struct bond_dev_private *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
- struct eth_driver *eth_drv = NULL;
struct rte_pci_driver *pci_drv = NULL;
- struct rte_pci_id *pci_id_table = NULL;
+
/* now do all data allocation - for eth_dev structure, dummy pci driver
* and internal (private) data
*/
@@ -195,26 +209,7 @@ rte_eth_bond_create(const char *name, uint8_t mode,
uint8_t socket_id)
goto err;
}
- eth_drv = rte_zmalloc_socket(name, sizeof(*eth_drv), 0, socket_id);
- if (eth_drv == NULL) {
- RTE_BOND_LOG(ERR, "Unable to malloc eth_drv on socket");
- goto err;
- }
-
- pci_drv = ð_drv->pci_drv;
-
- pci_id_table = rte_zmalloc_socket(name, sizeof(*pci_id_table), 0,
socket_id);
- if (pci_id_table == NULL) {
- RTE_BOND_LOG(ERR, "Unable to malloc pci_id_table on socket");
- goto err;
- }
- pci_id_table->device_id = PCI_ANY_ID;
- pci_id_table->subsystem_device_id = PCI_ANY_ID;
- pci_id_table->vendor_id = PCI_ANY_ID;
- pci_id_table->subsystem_vendor_id = PCI_ANY_ID;
-
- pci_drv->id_table = pci_id_table;
- pci_drv->drv_flags = RTE_PCI_DRV_INTR_LSC;
+ pci_drv = &rte_bond_pmd.pci_drv;
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, socket_id);
if (internals == NULL) {
@@ -233,7 +228,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t
socket_id)
pci_drv->name = pmd_bond_driver_name;
pci_dev->driver = pci_drv;
- eth_dev->driver = eth_drv;
+ eth_dev->driver = &rte_bond_pmd;
eth_dev->data->dev_private = internals;
eth_dev->data->nb_rx_queues = (uint16_t)1;
eth_dev->data->nb_tx_queues = (uint16_t)1;
@@ -289,13 +284,42 @@ rte_eth_bond_create(const char *name, uint8_t mode,
uint8_t socket_id)
err:
rte_free(pci_dev);
- rte_free(pci_id_table);
- rte_free(eth_drv);
rte_free(internals);
+ rte_free(eth_dev->data->mac_addrs);
return -1;
}
+int
+rte_eth_bond_free(const char *name)
+{
+ struct rte_eth_dev *e
[dpdk-dev] ixgbe_recv_scattered_pkts_vec split_flags question
On Tue, Jul 21, 2015 at 04:09:59PM +0100, Zoltan Kiss wrote:
> Hi,
>
> I have a question regarding split_flags in this question. It's defined as an
> array of 1 byte unsigned ints:
>
> uint8_t split_flags[RTE_IXGBE_VPMD_RX_BURST] = {0};
>
> RTE_IXGBE_VPMD_RX_BURST is 32, so it will be 32 bytes. Then we cast it into
> a pointer for 4 byte values, and check the first 4 elements of that array
>
> const uint32_t *split_fl32 = (uint32_t *)split_flags;
> if (rxq->pkt_first_seg == NULL &&
> split_fl32[0] == 0 && split_fl32[1] == 0 &&
> split_fl32[2] == 0 && split_fl32[3] == 0)
>
> So we only check the first half of this 32 byte array. But
> _recv_raw_pkts_vec() seems to use the whole array. Is this a bug or a
> feature? Or am I mistaken in the math somewhere?
>
> Regards,
>
> Zoltan Kiss
Yes, you are right, this does look like a bug. The uint32_t's should probably be
uint64_t's. :-(
/Bruce
[dpdk-dev] [PATCH] ixgbe: fix check for split packets
The check for split packets to be reassembled in the vector ixgbe PMD
was incorrectly only checking the first 16 elements of the array instead
of all 32. This is fixed by changing the uint32_t values to be uint64_t
instead.
Fixes: cf4b4708a88a ("ixgbe: improve slow-path perf with vector scattered Rx")
Reported-by: Zoltan Kiss
Signed-off-by: Bruce Richardson
---
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index 9f24849..cdad3e0 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -549,7 +549,7 @@ ixgbe_recv_scattered_pkts_vec(void *rx_queue, struct
rte_mbuf **rx_pkts,
return 0;
/* happy day case, full burst + no packets to be joined */
- const uint32_t *split_fl32 = (uint32_t *)split_flags;
+ const uint64_t *split_fl32 = (uint64_t *)split_flags;
if (rxq->pkt_first_seg == NULL &&
split_fl32[0] == 0 && split_fl32[1] == 0 &&
split_fl32[2] == 0 && split_fl32[3] == 0)
--
1.8.3.1
[dpdk-dev] [PATCH 1/1] ip_pipeline: fixed parsing cpu cores
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maciej Gajdzica
> Sent: Tuesday, July 21, 2015 3:39 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/1] ip_pipeline: fixed parsing cpu cores
>
> This patch fixes parsing value of core variable in pipeline config.
> Before not every combination of cores (c), sockets (s) and
> hyperthreading (h) was parsed correctly.
>
> Signed-off-by: Maciej Gajdzica
> ---
> examples/ip_pipeline/config_parse.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/examples/ip_pipeline/config_parse.c
> b/examples/ip_pipeline/config_parse.c
> index 361bf8a..c9b78f9 100644
> --- a/examples/ip_pipeline/config_parse.c
> +++ b/examples/ip_pipeline/config_parse.c
> @@ -386,14 +386,14 @@ parse_pipeline_core(uint32_t *socket,
> switch (type) {
> case 's':
> case 'S':
> - if (s_parsed)
> + if (s_parsed || c_parsed || h_parsed)
> return -EINVAL;
> s_parsed = 1;
> next++;
> break;
> case 'c':
> case 'C':
> - if (c_parsed)
> + if (c_parsed || h_parsed)
> return -EINVAL;
> c_parsed = 1;
> next++;
> @@ -423,7 +423,10 @@ parse_pipeline_core(uint32_t *socket,
> num[num_len] = *next;
> }
>
> - if (num_len == 0 && type != 'h')
> + if (num_len == 0 && type != 'h' && type != 'H')
> + return -EINVAL;
> +
> + if (num_len != 0 && (type == 'h' || type == 'H'))
> return -EINVAL;
>
> num[num_len] = '\0';
> @@ -438,9 +441,6 @@ parse_pipeline_core(uint32_t *socket,
> case 'c':
> case 'C':
> c = val;
> - if (type == 'C' && *next != '\0')
> - return -EINVAL;
> -
> break;
> case 'h':
> case 'H':
> --
> 1.7.9.5
Acked-by: Cristian Dumitrescu
[dpdk-dev] [PATCH v4 1/1] ring: changes to support PCI Port Hotplug
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, July 18, 2015 9:28 PM
> To: Iremonger, Bernard
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 1/1] ring: changes to support PCI Port
> Hotplug
>
> 2015-07-07 14:09, Bernard Iremonger:
> > +static struct eth_driver rte_ring_pmd = {
> > + .pci_drv = {
>
> We really have to stop faking PCI.
> EAL must be changed to allow non-PCI drivers without workaround.
> A device can have no bus (virtual device) or a PCI bus or another one.
>
> Let's rework EAL for release 2.2 before integrating this patch.
The fake pci _drv is already used in the pcap and null pmds and in the
original ring driver.
Could they not all be reworked when the EAL is changed for 2.2.
Surely we should be working with the 2.1 EAL.
Regards,
Bernard.
[dpdk-dev] [ovs-discuss] vswitches performance comparison
> -Original Message- > From: discuss [mailto:discuss-bounces at openvswitch.org] On Behalf Of Jun > Xiao > Sent: Tuesday, July 21, 2015 7:01 PM > To: discuss; dev > Subject: [ovs-discuss] vswitches performance comparison > > After CloudNetEngine vswitch technical preview is launched, we received > quite a few queries on vswitches performance comparison, but we cannot > simply give a test result on our platform because performance varies on > different H/Ws and different workloads, and that's why we encourage you to > try the evaluation package to get real data on your setup. > > Anyway, we share a little more performance data on our H/W which is a > comparison among native kernel OVS/OVS-DPDK/CNE vswitch under the > most common workload: > concurrent bi-directional TCP traffics cross hosts, and hope you can have a > rough idea. > http://www.cloudnetengine.com/weblog/2015/07/22/vswitches- > performance-comparison/ I think there is an issue with you methodology. ovs-dpdk performance should be significantly higher than kernel ovs. > > Thanks, > Jun > ___ > discuss mailing list > discuss at openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss
[dpdk-dev] [ovs-discuss] vswitches performance comparison
> > I'd like to hope that's my methodology problem, but I just follow the > installation guide without any customization. > > Hi Mark, do you have any performance data share with us? Maybe we are > using different type of workloads, like I mentioned I am using typical data > center workload, I guess you are talking about NFV type of workload? The number getting floated around on the mailing list recently is 16.5Mpps for phy-phy. However, I don't think we have any iperf data off-hand for your usecase. When we test throughput into the vm we usually generate the traffic externally and send NIC->OVS->VM->OVS->NIC. This is a little different to your setup. I do know, however, that ovs-dpdk typically has a much larger throughput than the kernel space datapath. Have you seen this? https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases > > Thanks, > Jun
[dpdk-dev] vswitches performance comparison
On Wed, 22 Jul 2015 02:00:42 +0800 "Jun Xiao" wrote: > After CloudNetEngine vswitch technical preview is launched, we received quite > a few queries on vswitches performance comparison, but we cannot simply give a > test result on our platform because performance varies on different H/Ws and > different workloads, and that's why we encourage you to try the evaluation > package to get real data on your setup. > > Anyway, we share a little more performance data on our H/W which is a > comparison > among native kernel OVS/OVS-DPDK/CNE vswitch under the most common workload: > concurrent bi-directional TCP traffics cross hosts, and hope you can have a > rough idea. > http://www.cloudnetengine.com/weblog/2015/07/22/vswitches-performance-comparison/ > > Thanks, > Jun Since the real bottleneck in most vswitches is per-packet overhead. I would recommend running RFC-2544 tests for better data. You probably need to use something like pktgen to get enough packets-per-second.
