[dpdk-dev] [RFC PATCH] eal: rte_rand yields only 62 random bits
Plus the driver and sched uses really only need of few bits of crap random number. Probably simple BSD random (32 bits) is more than enough On Mon, Mar 30, 2015 at 6:51 PM, Neil Horman wrote: > On Mon, Mar 30, 2015 at 06:19:28PM -0400, Robert Sanford wrote: > > Yes, applications have many choices for PRNGs. But, we still need one > > internally for the following libs: PMDs (e1000, fm10k, i40e, ixgbe, > virtio, > > xenvirt), sched, and timer. > > > They can be updated to use the apropriate rng from an external library. > Neil > > > > > On Fri, Mar 27, 2015 at 8:03 PM, Stephen Hemminger < > > stephen at networkplumber.org> wrote: > > > I would argue remove rte_rand from DPDK. > > > > > > > > On Mon, Mar 30, 2015 at 1:28 AM, Stephen Hemminger < > > stephen at networkplumber.org> wrote: > > > > > if some one needs PRNG, th GNU scientific library has lots of them > > > > > > > https://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html > > > > > > On Fri, Mar 27, 2015 at 5:38 PM, Matthew Hall > > > wrote: > > > > > > > On Fri, Mar 27, 2015 at 05:03:02PM -0700, Stephen Hemminger wrote: > > > > > I would argue remove rte_rand from DPDK. > > > > > > > > +1 > > > > > > > > To paraphrase Donald Knuth, "Random numbers should not be generated > > > [using > > > > a > > > > function coded] at random." > > > > > > > > It'd be better to fix libc, or considering that has a slow dev cycle > and > > > > platform compatibility limits, use some simple, semi-random, > > > > high-performance > > > > BSD licensed routine from a known-good library. > > > > > > > > Matthew. > > > > > > > > > >
[dpdk-dev] [PATCH] maintainers: claim pcap pmd library
> > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -247,6 +247,7 @@ F: lib/librte_pmd_vmxnet3/ > > > F: doc/guides/prog_guide/poll_mode_drv_paravirtual_vmxnets_nic.rst > > > > > > PCAP PMD > > > +M: Nicol?s Pernas Maradei > > > F: lib/librte_pmd_pcap/ > > > F: doc/guides/prog_guide/libpcap_ring_based_poll_mode_drv.rst > > > > Thomas, could you add my name as co-maintainer. If necessary I can submit a > > separate patch. > > > > Acked-by: John McNamara > > Acked-by Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH v4 0/7] Move EAL common function
2015-03-30 16:15, Ravi Kerur: > On Mon, Mar 30, 2015 at 2:29 PM, Thomas Monjalon 6wind.com> wrote: > > Sorry for not integrating this big refactoring in release 2.0. > > It wasn't easy to merge it during development of some EAL features. > > And it's now too risky to rework it before the release. > > I think this clean-up is needed and should be done at the beginning of 2.1 > > cycle. We just need to rebase it and remove the "ifdef BSD/LINUX" which was > > introduced in pci code. > > > > Do you think you'll have time for it? > > Sure, please let me know when it is needed I can work on it. 2.1 cycle is starting in few days. So the sooner is the better. Thanks a lot Ravi
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
2015-03-19 17:48, Thomas Monjalon: > Too many things are included in the programmers guide. > I think it should cover only API and knowledge needed to make an application. > That's why I suggest to move Xen and NICs doc outside. > Then it will be easier to add doc for a new environment or a new NIC. > Note that drivers or device-related libs like KNI, vhost or bonding stay > in the programmer's guide because they are more high-level than NICs drivers. > > Changes in v2: > - create index for Xen guide > - rename figure links > - rebase with mlx4 > - HTML copyright removal has been sent separately > > Thomas Monjalon (3): > doc: fix file attributes > doc: move Xen guide out of programmers guide > doc: nics guide Applied with figures list restored on Bernard's request.
[dpdk-dev] [PATCH] doc: prog guide cleanup for eal multi-pthread
2015-03-04 08:51, Cunming Liang: > Reported-by: Butler, Siobhan A > Signed-off-by: Cunming Liang > --- > Fixes: 1733be6d3147(doc: new eal multi-pthread feature) Note: "Fixes" tag should be part of the commit message, above other tags. Applied, thanks
[dpdk-dev] [PATCH] doc: added missing new EAL options in testpmd UG
> > Added information on testpmd user guide > > for -l, --lcores and --master-lcore options > > > > Signed-off-by: Pablo de Lara > > Acked-by Siobhan Butler There is a small error: doc/guides/testpmd_app_ug/run_app.rst:58: WARNING: Definition list ends without a blank line; unexpected unindent. Applied with small fix, thanks
[dpdk-dev] [PATCH 0/2] doc: update release notes for jobstats and bonding mode 6
> Update release notes for jobstats and bonding mode 6. > > Pawel Wodkowski (2): > doc: update bonding mode 6 release notes > doc: add jobstats library and application release notes Applied, thanks
[dpdk-dev] [PATCH v2] doc: add l2fwd-jobstats user guide
2015-03-27 15:33, De Lara Guarch, Pablo: > > Signed-off-by: Pawel Wodkowski > > --- > > > > Changes v2 > > 1. Fix trailing spaces and typos. > > 2. Add maintaners claim > > PDF will not build due to the extension of the images. Can you change them > from ".svg" to ".*"? Applied with above fix, thanks
[dpdk-dev] [PATCH] doc: replace DPDK.xyz.mk by rte.xyz.mk
> There are some references to DPDK.xyz.mk files that do not exist in the > dpdk tree. This was probably the result of an automatic replacement, so > restore the proper file names which are rte.xyz.mk. > > Signed-off-by: Olivier Matz Applied, thanks
[dpdk-dev] [PATCH 0/2] doc: update offload API
> Document the offload API and the testpmd commands related > to the checksum forward engine. > > Olivier Matz (2): > doc: update testpmd guide about csum forward engine > doc: add a description of the offload API Applied, thanks
[dpdk-dev] [PATCH] doc: add note on needing igb_uio module for VF devs
2015-03-25 15:02, Butler, Siobhan A: > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > > Sent: Wednesday, March 25, 2015 10:43 AM > > To: Richardson, Bruce; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] doc: add note on needing igb_uio module > > for VF devs > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson > > > Sent: Monday, March 23, 2015 4:20 PM > > > To: dev at dpdk.org > > > Subject: [dpdk-dev] [PATCH] doc: add note on needing igb_uio module > > > for VF devs > > > > > > Since the uio_pci_generic module requires that the device to which it > > > is being bound supports legacy interrupts, there can be problems using > > > it with VF devices. Add a note to the GSG doc to document this fact, and > > provide information on loading igb_uio as a replacement. > > > > > > Signed-off-by: Bruce Richardson > > > > Acked-by: Bernard Iremonger > > Acked-by: Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH] doc: Update doc for ixgbe VF RSS
> Since the following commit has already been merged into dpdk.org mainline, > commit: 42d2f78abcb77ecb769be4149df550308169ef0f > > So update the prog guide for it. > > Signed-off-by: Changchun Ouyang Applied, thanks
[dpdk-dev] [PATCH] doc: add warning for fm10k early driver
2015-03-22 11:32, Siobhan Butler: > This patch adds a note to the release notes new features, > as a warning regarding the early status of the FM10K driver for pre-release > access > > Signed-off-by: Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH] doc: New option for vhost sample
> > Since codes for this new option(--vlan-strip) are already merged into > > mainline, > > see: commit: e3d61d1609cb9b3ea851c7776bfbb60dcfe8844a. > > > > So the doc need update for that. > > > > Signed-off-by: Changchun Ouyang > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] vhost library doc update
> > add vhost user documentation > > > > Signed-off-by: Huawei Xie > > Acked-by Siobhan Butler doc/guides/prog_guide/vhost_lib.rst:114: ERROR: Unexpected indentation. Applied with above fix, thanks
[dpdk-dev] [PATCH] vhost example doc update
> add vhost user documentation > fix some minor issues > > Signed-off-by: Huawei Xie Applied, thanks
[dpdk-dev] [PATCH v4] doc: Update doc for vhost sample
> > From: Ouyang Changchun > > > > Added some documentation on common issues for the vhost sample app > > and how to resolve them. > > > > Signed-off-by: Changchun Ouyang > > Signed-off-by: John McNamara > > Acked-by Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH] doc: update of testpmd user guide
> > It updated the user guide of testpmd, for the newly supported commands > > of getting/setting hash functions, and the command of showing port > > information. > > > > Signed-off-by: Helin Zhang > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] doc: added to faq section of release notes
> Added some of the questions posted to the mailing list to the FAQ section of > release notes. > > Signed-off-by: Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH v2] doc: update release notes description for new sample apps
> Updated release notes release description notes: > - added new sample applications to list: Link Bonding,Skeleton, Callbacks, > Jobstats > - updated copyright date to 2015 > - updated release number form 1.7.0 to 2.0 > > Signed-off-by: Siobhan Butler Applied, thanks
[dpdk-dev] [PATCH] doc: updated tested OS list in release notes
> Updated Operating Systems tested during 2.0 in release notes > > Signed-off-by: Siobhan Butler Applied, thanks
[dpdk-dev] [dpdk-announce] release candidate 2.0.0-rc3
A new DPDK release candidate is ready for testing: http://dpdk.org/browse/dpdk/tag/?id=v2.0.0-rc3 It is the last week to send your fixes before the release. Please check how you might help to review the last patches: http://dpdk.org/dev/patchwork Changelog (main changes since 2.0.0-rc2) - enhancements: * PDF doc output * NICs guide * Rx callback parameter - fixes for: * doc * build * multiprocess * igb * ixgbe * i40e * enic * virtio * vhost * bond * packet framework * testpmd A lot of patches have been reviewed efficiently these last weeks. It seems having some identified maintainers for dedicated areas helps a lot. Thank you everyone!
[dpdk-dev] Inputs needed - testing l2fwd
On Wed, Mar 25, 2015 at 11:55 AM, Shankari Vaidyalingam < shankari.v2k6 at gmail.com> wrote: > > +dpdk-dev > >> Thanks for the response. >> >> I'm using Intel 82545 EM as the network adapter type and not using >> virtio-net >> I also checked whether 82545 NIC is supported by DPDK and found that it >> is supported. >> >> Regards >> Shankari.V >> >> On Wed, Mar 25, 2015 at 10:38 AM, Stephen Hemminger < >> stephen at networkplumber.org> wrote: >> >>> On Wed, 25 Mar 2015 09:40:47 +0530 >>> Shankari Vaidyalingam wrote: >>> >>> > Hi, >>> > >>> > Can anyone please help me whether I'm missing something in the below >>> > exercise >>> > >>> > Regards >>> > Shankari.V >>> > >>> > On Wed, Mar 25, 2015 at 12:25 AM, Shankari Vaidyalingam < >>> > shankari.v2k6 at gmail.com> wrote: >>> > >>> > > I'm trying to run sample DPDK applications by injecting packets >>> from an >>> > > external traffic generator. >>> > > I'm not able to get the frames to reach the RX queue of the >>> corresponding >>> > > port and make the PMD detect those packets and get the application >>> process >>> > > them. >>> > > >>> > > My configuration is: >>> > > >>> > > I'm using Oracle VirtualBox to have 2 virtual network adapters for >>> use in >>> > > the sample application. I have configured both the network adapters >>> in the >>> > > "Bridged Networking" mode. >>> > > When I open the VM I can see the interfaces - eth0 and eth1 >>> > > I bound the 2 interfaces to igb_uio driver and then configured the >>> > > hugepage mapping. >>> > > When I try sending the frames from an external source I had set the >>> dest >>> > > MAC to the MAC addr of the ports bound to DPDK. >>> > > But still I'm not able to see either the "Frames received" or "Frames >>> > > dropped" count getting incremented. >>> > > >>> > > I tried googling and tried various options for networking mode as >>> > > (Bridged/Host Only...) but none of them seem to work fine. >>> > > >>> > > I'm sure that I'm missing something. >>> > > Can you please help me in this regard. >>> > > >>> > > Regards >>> > > Shankari.V >>> > > >>> > > >>> >>> VirtualBox has its own version of virtio which is not compatiable >>> with the current version of DPDK virtio driver. >>> >> >> > Hi, I'm still facing the issue where I'm not able to receive the frames in the l2fwd app that I'm running on the VM. I also tried googling and read similar posts in the discussion lists but not able to get the frames in the l2fwd app. I've created the VMs using Oracle VirtualBox. If anyone has tried using VirtualBox please let me know how to resolve this. I tried running in both the ways but it didnt work: (1) Configuration inside a VM: Traffic gen --> eth0 ---> L2fwd app -> eth1 (2) Traffic gen > eth0 > VM (eth0) -> L2fwd app -> VM (eth1) Regards Shankari.V
[dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu > Sent: Thursday, February 12, 2015 7:22 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork > > Klocwork reports array 'src_offset' may use index 16. > In function i40e_srcoff_to_flx_pit, index j + 1 can reach > I40E_FDIR_MAX_FLEX_LEN. > This patch fixes this issue to avoid array bound. > > Signed-off-by: Jingjing Wu Acked-by: Helin Zhang > --- > lib/librte_pmd_i40e/i40e_fdir.c | 35 +-- > 1 file changed, 17 insertions(+), 18 deletions(-)
[dpdk-dev] [PATCH] fm10k: Fix queue start twice failed
Hi, Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, March 31, 2015 4:02 AM > To: Qiu, Michael > Cc: dev at dpdk.org; Chen, Jing D > Subject: Re: [dpdk-dev] [PATCH] fm10k: Fix queue start twice failed > > 2015-03-25 18:48, Michael Qiu: > > When use "port 0 rxq 0 start" in testpmd twice, the rx queue 0 on > > port 0 will failed to work. > > > > The root casue is the rxqctl enable bit need to reset if already > > enabled. > > Please try to reword this message to make it clear. > > > Signed-off-by: Michael Qiu > > --- > > lib/librte_pmd_fm10k/fm10k_ethdev.c | 56 +--- > - > > 1 file changed, 32 insertions(+), 24 deletions(-) > > Jing, should it enter in 2.0? Michael and I discussed and thought it's not the best solution to fix this issue. So, we'd like postpone this fix. Thanks! >
[dpdk-dev] [PATCH v3] ixgbe: fix data access on big endian cpu
From: Xuelin Shi
enforce rules of the cpu and ixgbe exchange data.
1. cpu use data owned by ixgbe must use rte_le_to_cpu_xx(...)
2. cpu fill data to ixgbe must use rte_cpu_to_le_xx(...)
3. checking pci status with converted constant.
Signed-off-by: Xuelin Shi
---
change for v3:
check pci status with converted constant to avoid performance penalty.
remove tmp variable.
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 89 ---
1 file changed, 56 insertions(+), 33 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 9da2c7e..6e508ec 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -129,7 +129,7 @@ ixgbe_tx_free_bufs(struct ixgbe_tx_queue *txq)
/* check DD bit on threshold descriptor */
status = txq->tx_ring[txq->tx_next_dd].wb.status;
- if (! (status & IXGBE_ADVTXD_STAT_DD))
+ if (!(status & rte_cpu_to_le_32(IXGBE_ADVTXD_STAT_DD)))
return 0;
/*
@@ -174,11 +174,14 @@ tx4(volatile union ixgbe_adv_tx_desc *txdp, struct
rte_mbuf **pkts)
pkt_len = (*pkts)->data_len;
/* write data to descriptor */
- txdp->read.buffer_addr = buf_dma_addr;
+ txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+
txdp->read.cmd_type_len =
- ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+ rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+
txdp->read.olinfo_status =
- (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+ rte_cpu_to_le_32(pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+
rte_prefetch0(&(*pkts)->pool);
}
}
@@ -194,11 +197,14 @@ tx1(volatile union ixgbe_adv_tx_desc *txdp, struct
rte_mbuf **pkts)
pkt_len = (*pkts)->data_len;
/* write data to descriptor */
- txdp->read.buffer_addr = buf_dma_addr;
+ txdp->read.buffer_addr = rte_cpu_to_le_64(buf_dma_addr);
+
txdp->read.cmd_type_len =
- ((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+ rte_cpu_to_le_32((uint32_t)DCMD_DTYP_FLAGS | pkt_len);
+
txdp->read.olinfo_status =
- (pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+ rte_cpu_to_le_32(pkt_len << IXGBE_ADVTXD_PAYLEN_SHIFT);
+
rte_prefetch0(&(*pkts)->pool);
}
@@ -285,7 +291,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
* a divisor of the ring size
*/
tx_r[txq->tx_next_rs].read.cmd_type_len |=
- rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
+ rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
txq->tx_next_rs = (uint16_t)(txq->tx_rs_thresh - 1);
txq->tx_tail = 0;
@@ -304,7 +310,7 @@ tx_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
*/
if (txq->tx_tail > txq->tx_next_rs) {
tx_r[txq->tx_next_rs].read.cmd_type_len |=
- rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
+ rte_cpu_to_le_32(IXGBE_ADVTXD_DCMD_RS);
txq->tx_next_rs = (uint16_t)(txq->tx_next_rs +
txq->tx_rs_thresh);
if (txq->tx_next_rs >= txq->nb_tx_desc)
@@ -505,6 +511,7 @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
uint16_t nb_tx_desc = txq->nb_tx_desc;
uint16_t desc_to_clean_to;
uint16_t nb_tx_to_clean;
+ uint32_t stat;
/* Determine the last descriptor needing to be cleaned */
desc_to_clean_to = (uint16_t)(last_desc_cleaned + txq->tx_rs_thresh);
@@ -513,7 +520,9 @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
/* Check to make sure the last descriptor to clean is done */
desc_to_clean_to = sw_ring[desc_to_clean_to].last_id;
- if (! (txr[desc_to_clean_to].wb.status & IXGBE_TXD_STAT_DD))
+
+ stat = txr[desc_to_clean_to].wb.status;
+ if (!(stat & rte_cpu_to_le_32(IXGBE_TXD_STAT_DD)))
{
PMD_TX_FREE_LOG(DEBUG,
"TX descriptor %4u is not done"
@@ -801,12 +810,14 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
*/
slen = m_seg->data_len;
buf_dma_addr = RTE_MBUF_DATA_DMA_ADDR(m_seg);
+
txd->read.buffer_addr =
- rte_cpu_to_le_64(buf_dma_addr);
+ rte_cpu_to_le_64(buf_dma_addr);
txd->read.cmd_type_len =
- rte_cpu_to_le_32(cmd_type_len | slen);
+ rte_cpu_to_le_32(cmd_type_len | slen);
txd->read.olinfo_status =
- rte_cpu_to_le_32(olinfo_
[dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork
Tested-by: Min Cao
Patch name: [dpdk-dev] [PATCH] i40e: fix the issue reported by
klocwork
Test Flag: Tested-by
Tester name:min.cao at intel.com
Result summary: total 2 cases, 2passed, 0 failed
Test Case 1:
Name: ipv4 fwd
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle
Test result:PASSED
Detail: ipv4 fwd
Test Case 2:
Name: ipv6 fwd
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle
Test result:PASSED
Detail: ipv6 fwd
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jingjing Wu
Sent: Thursday, February 12, 2015 7:22 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork
Klocwork reports array 'src_offset' may use index 16.
In function i40e_srcoff_to_flx_pit, index j + 1 can reach
I40E_FDIR_MAX_FLEX_LEN.
This patch fixes this issue to avoid array bound.
Signed-off-by: Jingjing Wu
---
lib/librte_pmd_i40e/i40e_fdir.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_fdir.c b/lib/librte_pmd_i40e/i40e_fdir.c
index 68511c8..bc36d8e 100644
--- a/lib/librte_pmd_i40e/i40e_fdir.c
+++ b/lib/librte_pmd_i40e/i40e_fdir.c
@@ -402,28 +402,27 @@ i40e_srcoff_to_flx_pit(const uint16_t *src_offset,
while (j < I40E_FDIR_MAX_FLEX_LEN) {
size = 1;
- for (; j < I40E_FDIR_MAX_FLEX_LEN; j++) {
+ for (; j < I40E_FDIR_MAX_FLEX_LEN - 1; j++) {
if (src_offset[j + 1] == src_offset[j] + 1)
size++;
- else {
- src_tmp = src_offset[j] + 1 - size;
- /* the flex_pit need to be sort by scr_offset */
- for (i = 0; i < num; i++) {
- if (src_tmp < flex_pit[i].src_offset)
- break;
- }
- /* if insert required, move backward */
- for (k = num; k > i; k--)
- flex_pit[k] = flex_pit[k - 1];
- /* insert */
- flex_pit[i].dst_offset = j + 1 - size;
- flex_pit[i].src_offset = src_tmp;
- flex_pit[i].size = size;
- j++;
- num++;
+ else
+ break;
+ }
+ src_tmp = src_offset[j] + 1 - size;
+ /* the flex_pit need to be sort by src_offset */
+ for (i = 0; i < num; i++) {
+ if (src_tmp < flex_pit[i].src_offset)
break;
- }
}
+ /* if insert required, move backward */
+ for (k = num; k > i; k--)
+ flex_pit[k] = flex_pit[k - 1];
+ /* insert */
+ flex_pit[i].dst_offset = j + 1 - size;
+ flex_pit[i].src_offset = src_tmp;
+ flex_pit[i].size = size;
+ j++;
+ num++;
}
return num;
}
--
1.9.3
[dpdk-dev] VFIO in setup.sh
> > 3. Why depend on location of vfio module in kernel tree? > >modprobe does the right thing and finds it. > > > > VFIO_PATH="kernel/drivers/vfio/pci/vfio-pci.ko" > > > > echo "Loading VFIO module" > > /sbin/lsmod | grep -s vfio_pci > /dev/null > > if [ $? -ne 0 ] ; then > > if [ -f /lib/modules/$(uname -r)/$VFIO_PATH ] ; then > > sudo /sbin/modprobe vfio-pci > > fi > > fi > > Here I agree. Needs to be fixed. Thanks, Anatoly
[dpdk-dev] VFIO in setup.sh
I think the whole process of VFIO binding maybe needs at least a second thought regarding corner cases and security. 1) in the setup process, there currently is no mechanism that checks if the Device to be used has other devices in the same iommu group that need to be bound to VFIO too. Otherwise using VFIO will fail. I think currently, it only works if the network device is the only one in its iommu group. 2) Right now everything inside /dev/vfio/ is granted to the all users, right? Maybe this leads to (security) issues if VFIO is in active use by other non-dpdk processes for other PCIe devices. Cheers, Andre Burakov, Anatoly schrieb am Di., 31. M?rz 2015 um 11:05: > > > 3. Why depend on location of vfio module in kernel tree? > > >modprobe does the right thing and finds it. > > > > > > VFIO_PATH="kernel/drivers/vfio/pci/vfio-pci.ko" > > > > > > echo "Loading VFIO module" > > > /sbin/lsmod | grep -s vfio_pci > /dev/null > > > if [ $? -ne 0 ] ; then > > > if [ -f /lib/modules/$(uname -r)/$VFIO_PATH ] ; then > > > sudo /sbin/modprobe vfio-pci > > > fi > > > fi > > > > > Here I agree. Needs to be fixed. > > Thanks, > Anatoly >
[dpdk-dev] VFIO in setup.sh
> I think the whole process of VFIO binding maybe needs at least a second > thought regarding corner cases and security. > > 1) in the setup process, there currently is no mechanism that checks if the > Device to be used has other devices in the > same iommu group that need to be bound to VFIO too. Otherwise using VFIO will > fail. > I think currently, it only works if the network device is the only one in its > iommu group. > > 2) Right now everything inside /dev/vfio/ is granted to the all users, right? > Maybe this leads to (security) issues if VFIO > is in active use by other non-dpdk processes for other PCIe devices. I believe that's how VFIO is meant to be used. At least according to VFIO documentation, located here: https://www.kernel.org/doc/Documentation/vfio.txt Regarding 1), this can only be done by unbinding the device from the host driver and binding it to vfio-pci, which can't be done by the user. If the device is not bound to vfio-pci, we have no way of knowing if it belongs to this or that IOMMU group. Regarding 2), as noted above, the administrator should set up VFIO devices. While I agree that the way setup.sh sets up VFIO security permissions is not ideal, it's really there to cover the most common use case. An administrator can always set up VFIO on his own, granting permissions as needed. Thanks, Anatoly
[dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Monday, March 30, 2015 4:57 PM
> To: Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
>
>
>
> On 03/30/15 18:37, Vlad Zolotarov wrote:
> >
> >
> > On 03/30/15 17:18, Ananyev, Konstantin wrote:
> >> Hi Vlad,
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> >>> Sent: Wednesday, March 18, 2015 5:52 PM
> >>> To: dev at dpdk.org
> >>> Subject: [dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
> >>>
> >>> - Only x540 and 82599 devices support LRO.
> >>> - Add the appropriate HW configuration.
> >>> - Add RSC aware rx_pkt_burst() handlers:
> >>> - Implemented bulk allocation and non-bulk allocation versions.
> >>> - Add LRO-specific fields to rte_eth_rxmode, to
> >>> rte_eth_dev_data
> >>> and to ixgbe_rx_queue.
> >>> - Use the appropriate handler when LRO is requested.
> >>>
> >>> Signed-off-by: Vlad Zolotarov
> >>> ---
> >>> New in v8:
> >>> - Took the RSC configuration code from ixgbe_dev_rx_init() into
> >>> a separate
> >>> function - ixgbe_set_rsc().
> >>> - Added some missing macros for HW configuration.
> >>> - Styling adjustments:
> >>>- Functions names.
> >>>- Functions descriptions.
> >>> - Reworked the ixgbe_free_rsc_cluster() code to make it more
> >>> readable.
> >>> - Kill the HEADER_SPLIT flow in ixgbe_set_rsc() since it's not
> >>> supported by
> >>> ixgbe PMD.
> >>>
> >>> New in v7:
> >>> - Free not-yet-completed RSC aggregations in rte_eth_dev_stop()
> >>> flow.
> >>> - Reset the sw_ring[].mbuf entry in a bulk allocation case.
> >>> This is needed for ixgbe_rx_queue_release_mbufs().
> >>> - _recv_pkts_lro(): added the missing memory barrier before RDT
> >>> update in a
> >>> non-bulk allocation case.
> >>> - Don't allow RSC when device is configured in an SR-IOV mode.
> >>>
> >>> New in v5:
> >>> - Put the RTE_ETHDEV_HAS_LRO_SUPPORT definition at the beginning
> >>> of rte_ethdev.h.
> >>> - Removed the "TODO: Remove me" comment near
> >>> RTE_ETHDEV_HAS_LRO_SUPPORT.
> >>>
> >>> New in v4:
> >>> - Define RTE_ETHDEV_HAS_LRO_SUPPORT in rte_ethdev.h instead of
> >>> RTE_ETHDEV_LRO_SUPPORT defined in config/common_linuxapp.
> >>>
> >>> New in v2:
> >>> - Removed rte_eth_dev_data.lro_bulk_alloc.
> >>> - Fixed a few styling and spelling issues.
> >>> ---
> >>> lib/librte_ether/rte_ethdev.h | 9 +-
> >>> lib/librte_net/rte_ip.h | 3 +
> >>> lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h | 6 +
> >>> lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 11 +
> >>> lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 5 +
> >>> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 610
> >>> +++-
> >>> lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 6 +
> >>> 7 files changed, 642 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/lib/librte_ether/rte_ethdev.h
> >>> b/lib/librte_ether/rte_ethdev.h
> >>> index 21aa359..61dc49a 100644
> >>> --- a/lib/librte_ether/rte_ethdev.h
> >>> +++ b/lib/librte_ether/rte_ethdev.h
> >>> @@ -172,6 +172,9 @@ extern "C" {
> >>>
> >>> #include
> >>>
> >>> +/* Use this macro to check if LRO API is supported */
> >>> +#define RTE_ETHDEV_HAS_LRO_SUPPORT
> >>> +
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -320,14 +323,15 @@ struct rte_eth_rxmode {
> >>> enum rte_eth_rx_mq_mode mq_mode;
> >>> uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame
> >>> enabled. */
> >>> uint16_t split_hdr_size; /**< hdr buf size (header_split
> >>> enabled).*/
> >>> -uint8_t header_split : 1, /**< Header Split enable. */
> >>> +uint16_t header_split : 1, /**< Header Split enable. */
> >>> hw_ip_checksum : 1, /**< IP/UDP/TCP checksum offload
> >>> enable. */
> >>> hw_vlan_filter : 1, /**< VLAN filter enable. */
> >>> hw_vlan_strip: 1, /**< VLAN strip enable. */
> >>> hw_vlan_extend : 1, /**< Extended VLAN enable. */
> >>> jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */
> >>> hw_strip_crc : 1, /**< Enable CRC stripping by
> >>> hardware. */
> >>> -enable_scatter : 1; /**< Enable scatter packets rx
> >>> handler */
> >>> +enable_scatter : 1, /**< Enable scatter packets rx
> >>> handler */
> >>> +enable_lro : 1; /**< Enable LRO */
> >>> };
> >>>
> >>> /**
> >>> @@ -1515,6 +1519,7 @@ struct rte_eth_dev_data {
> >>> uint8_t port_id; /**< Device [external] port
> >>> identifier. */
> >>> uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) /
> >>> OFF(0). */
> >>> scattered_rx : 1, /**< RX of scattered packets is ON(1) /
> >>> OFF(0) */
> >>> +lro : 1, /**< RX LRO is ON(1) / OFF(0
[dpdk-dev] [PATCH] i40e: fix the issue reported by klocwork
Hi Helin, > > Klocwork reports array 'src_offset' may use index 16. > > In function i40e_srcoff_to_flx_pit, index j + 1 can reach > > I40E_FDIR_MAX_FLEX_LEN. > > This patch fixes this issue to avoid array bound. > > > > Signed-off-by: Jingjing Wu > Acked-by: Helin Zhang Please confirm it's a real bug which needs to be fixed in 2.0, and/or you are sure this patch won't bring a new problem. Thanks
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, March 31, 2015 12:38 AM > To: Butler, Siobhan A > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > 2015-03-19 17:48, Thomas Monjalon: > > Too many things are included in the programmers guide. > > I think it should cover only API and knowledge needed to make an > application. > > That's why I suggest to move Xen and NICs doc outside. > > Then it will be easier to add doc for a new environment or a new NIC. > > Note that drivers or device-related libs like KNI, vhost or bonding > > stay in the programmer's guide because they are more high-level than > NICs drivers. > > > > Changes in v2: > > - create index for Xen guide > > - rename figure links > > - rebase with mlx4 > > - HTML copyright removal has been sent separately > > > > Thomas Monjalon (3): > > doc: fix file attributes > > doc: move Xen guide out of programmers guide > > doc: nics guide > > Applied with figures list restored on Bernard's request. Hi, Any objection to an additional patch to move the figure captions below the figures in the docs? The caption above the figure was the format used in the initial docs, and it looks okay in the HTML output, but in the PDF output it tends to get merged into the preceding paragraph and isn't always on the same page as the figure. John
[dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
On 03/31/15 13:25, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Monday, March 30, 2015 4:57 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
>>
>>
>>
>> On 03/30/15 18:37, Vlad Zolotarov wrote:
>>>
>>> On 03/30/15 17:18, Ananyev, Konstantin wrote:
Hi Vlad,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> Sent: Wednesday, March 18, 2015 5:52 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v8 3/3] ixgbe: Add LRO support
>
> - Only x540 and 82599 devices support LRO.
> - Add the appropriate HW configuration.
> - Add RSC aware rx_pkt_burst() handlers:
> - Implemented bulk allocation and non-bulk allocation versions.
> - Add LRO-specific fields to rte_eth_rxmode, to
> rte_eth_dev_data
>and to ixgbe_rx_queue.
> - Use the appropriate handler when LRO is requested.
>
> Signed-off-by: Vlad Zolotarov
> ---
> New in v8:
> - Took the RSC configuration code from ixgbe_dev_rx_init() into
> a separate
>function - ixgbe_set_rsc().
> - Added some missing macros for HW configuration.
> - Styling adjustments:
> - Functions names.
> - Functions descriptions.
> - Reworked the ixgbe_free_rsc_cluster() code to make it more
> readable.
> - Kill the HEADER_SPLIT flow in ixgbe_set_rsc() since it's not
> supported by
>ixgbe PMD.
>
> New in v7:
> - Free not-yet-completed RSC aggregations in rte_eth_dev_stop()
> flow.
> - Reset the sw_ring[].mbuf entry in a bulk allocation case.
>This is needed for ixgbe_rx_queue_release_mbufs().
> - _recv_pkts_lro(): added the missing memory barrier before RDT
> update in a
>non-bulk allocation case.
> - Don't allow RSC when device is configured in an SR-IOV mode.
>
> New in v5:
> - Put the RTE_ETHDEV_HAS_LRO_SUPPORT definition at the beginning
> of rte_ethdev.h.
> - Removed the "TODO: Remove me" comment near
> RTE_ETHDEV_HAS_LRO_SUPPORT.
>
> New in v4:
> - Define RTE_ETHDEV_HAS_LRO_SUPPORT in rte_ethdev.h instead of
>RTE_ETHDEV_LRO_SUPPORT defined in config/common_linuxapp.
>
> New in v2:
> - Removed rte_eth_dev_data.lro_bulk_alloc.
> - Fixed a few styling and spelling issues.
> ---
>lib/librte_ether/rte_ethdev.h | 9 +-
>lib/librte_net/rte_ip.h | 3 +
>lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h | 6 +
>lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 11 +
>lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 5 +
>lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 610
> +++-
>lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 6 +
>7 files changed, 642 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_ether/rte_ethdev.h
> b/lib/librte_ether/rte_ethdev.h
> index 21aa359..61dc49a 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -172,6 +172,9 @@ extern "C" {
>
>#include
>
> +/* Use this macro to check if LRO API is supported */
> +#define RTE_ETHDEV_HAS_LRO_SUPPORT
> +
>#include
>#include
>#include
> @@ -320,14 +323,15 @@ struct rte_eth_rxmode {
>enum rte_eth_rx_mq_mode mq_mode;
>uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame
> enabled. */
>uint16_t split_hdr_size; /**< hdr buf size (header_split
> enabled).*/
> -uint8_t header_split : 1, /**< Header Split enable. */
> +uint16_t header_split : 1, /**< Header Split enable. */
>hw_ip_checksum : 1, /**< IP/UDP/TCP checksum offload
> enable. */
>hw_vlan_filter : 1, /**< VLAN filter enable. */
>hw_vlan_strip: 1, /**< VLAN strip enable. */
>hw_vlan_extend : 1, /**< Extended VLAN enable. */
>jumbo_frame : 1, /**< Jumbo Frame Receipt enable. */
>hw_strip_crc : 1, /**< Enable CRC stripping by
> hardware. */
> -enable_scatter : 1; /**< Enable scatter packets rx
> handler */
> +enable_scatter : 1, /**< Enable scatter packets rx
> handler */
> +enable_lro : 1; /**< Enable LRO */
>};
>
>/**
> @@ -1515,6 +1519,7 @@ struct rte_eth_dev_data {
>uint8_t port_id; /**< Device [external] port
> identifier. */
>uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) /
> OFF(0). */
>scattered_rx : 1, /**< RX of sca
[dpdk-dev] [PATCH v9 0/3]: Add LRO support to ixgbe PMD
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> Sent: Monday, March 30, 2015 8:21 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v9 0/3]: Add LRO support to ixgbe PMD
>
> This series adds the missing flow for enabling the LRO in the ethdev and
> adds a support for this feature in the ixgbe PMD. There is a big hope that
> this
> initiative is going to be picked up by some Intel developer that would add
> the LRO support
> to other Intel PMDs.
>
> The series starts with some cleanup work in the code the final patch (the
> actual adding of
> the LRO support) is going to touch/use/change. There are still quite a few
> issues in the ixgbe
> PMD code left but they have to be a matter of a different series and I've
> left a few "TODO"
> remarks in the code.
>
> The LRO ("RSC" in Intel's context) PMD completion handling code follows the
> same design as the
> corresponding Linux and FreeBSD implementation: pass the aggregation's
> cluster HEAD buffer to
> the NEXTP entry of the software ring till EOP is met.
>
> HW configuration follows the corresponding specs: this feature is supported
> only by x540 and
> 82599 PF devices.
>
> The feature has been tested with seastar TCP stack with the following
> configuration on Tx side:
>- MTU: 400B
>- 100 concurrent TCP connections.
>
> The results were:
>- Without LRO: total throughput: 0.12Gbps, coefficient of variance: 1.41%
>- With LRO:total throughput: 8.21Gbps, coefficient of variance: 0.59%
>
> This is an almost factor 80 improvement.
>
> New in v9:
>- Move newly added IXGBE_XXX macros to ixgbe_ethdev.h.
>
> New in v8:
>- Fixed the structs naming: igb_xxx -> ixgbe_xxx (some leftovers in
> PATCH2).
>- Took the RSC configuration code from ixgbe_dev_rx_init() into a separate
> function - ixgbe_set_rsc().
>- Added some missing macros for HW configuration.
>- Styling adjustments:
> - Functions names.
> - Functions descriptions.
>- Reworked the ixgbe_free_rsc_cluster() code to make it more readable.
>- Kill the HEADER_SPLIT flow in ixgbe_set_rsc() since it's not supported by
> ixgbe PMD.
>
> New in v7:
>- Free not-yet-completed RSC aggregations in rte_eth_dev_stop() flow.
>- Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
> - Don't set them to FALSE in rte_eth_dev_stop() flow - the following
> rte_eth_dev_start() will need them.
> - Reset them to TRUE in rte_eth_dev_configure() and not in a probe()
> flow.
> This will ensure the proper behaviour if port is re-configured.
>- Reset the sw_ring[].mbuf entry in a bulk allocation case.
> This is needed for ixgbe_rx_queue_release_mbufs().
>- _recv_pkts_lro(): added the missing memory barrier before RDT update in a
> non-bulk allocation case.
>- Don't allow RSC when device is configured in an SR-IOV mode.
>
> New in v6:
>- Fix of the typo in the "bug fixes" series that broke the compilation
> caused a
> minor change in this follow-up series.
>
> New in v5:
>- Split the series into "bug fixes" and "all the rest" so that the former
> could be
> integrated into a 2.0 release.
>- Put the RTE_ETHDEV_HAS_LRO_SUPPORT definition at the beginning of
> rte_ethdev.h.
>- Removed the "TODO: Remove me" comment near RTE_ETHDEV_HAS_LRO_SUPPORT.
>
> New in v4:
>- Remove CONFIG_RTE_ETHDEV_LRO_SUPPORT from config/common_linuxapp.
>- Define RTE_ETHDEV_HAS_LRO_SUPPORT in rte_ethdev.h.
>- As a result of "ixgbe: check rxd number to avoid mbuf leak" (352078e8e)
> Vector Rx
> had to get the same treatment as Rx Bulk Alloc (see PATCH4 for more
> details).
>
> New in v3:
>- ixgbe_rx_alloc_bufs(): Always reset refcnt of the buffers to 1.
> Otherwise rte_pktmbuf_free()
> won't free them.
>
> New in v2:
>- Removed rte_eth_dev_data.lro_bulk_alloc and added
> ixgbe_hw.rx_bulk_alloc_allowed
> instead.
>- Unified the rx_pkt_bulk callback setting (a separate new patch).
>- Fixed a few styling and spelling issues.
>
> Vlad Zolotarov (3):
> ixgbe: Cleanups
> ixgbe: Code refactoring
> ixgbe: Add LRO support
>
> lib/librte_ether/rte_ethdev.h | 9 +-
> lib/librte_net/rte_ip.h | 3 +
> lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 11 +
> lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 13 +
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 765
>
> lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 6 +
> 6 files changed, 738 insertions(+), 69 deletions(-)
>
> --
Acked-by: Konstantin Ananyev for 2.1 release.
> 2.1.0
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
2015-03-31 11:34, Mcnamara, John: > Any objection to an additional patch to move the figure captions below > the figures in the docs? No objection. We should use figure:: keyword instead of image:: to add a caption. > The caption above the figure was the format used in the initial docs, > and it looks okay in the HTML output, but in the PDF output it tends > to get merged into the preceding paragraph and isn't always on the > same page as the figure. Yes, it's a bit strange. Why moving it below will ensure to keep it in the same page? I think figure:: keyword may solve it.
[dpdk-dev] [PATCH] mbuf: add comment explaining confusing code
Hi, On 30/03/15 18:39, Don Provan wrote: > if (likely (rte_mbuf_refcnt_read(m) == 1) || > likely (rte_mbuf_refcnt_update(m, -1) == 0)) > > In all the debate about atomics, I don't think anyone got around to pointing > out that in the unlikely case that the refcnt is not 1, then it's equally > unlikely that decrementing it will result in 0 despite the code's claim to > the contrary. That's the part that confused me. Would it make sense to fix > this while adding the comment? > -don > dprovan at bivio.net > I was thinking about that too, either remove it or turn it into "unlikely". Currently it suggest that "if there are more than one users, they are likely to release at the same time". If that's not true, we should remove it, but as Don said, it would hardly make a difference in real world cases as more than one users is not really a hot usecase, AFAIK. Regards, Zoltan
[dpdk-dev] VFIO in setup.sh
2015-03-31 11:35 GMT+02:00 Burakov, Anatoly : > > > I think the whole process of VFIO binding maybe needs at least a second > > thought regarding corner cases and security. > > > > 1) in the setup process, there currently is no mechanism that checks if the > > Device to be used has other devices in the > > same iommu group that need to be bound to VFIO too. Otherwise using VFIO > > will fail. > > I think currently, it only works if the network device is the only one in > > its iommu group. > > > > 2) Right now everything inside /dev/vfio/ is granted to the all users, > > right? Maybe this leads to (security) issues if VFIO > > is in active use by other non-dpdk processes for other PCIe devices. > > I believe that's how VFIO is meant to be used. At least according to VFIO > documentation, located here: https://www.kernel.org/doc/Documentation/vfio.txt > > Regarding 1), this can only be done by unbinding the device from the host > driver and binding it to vfio-pci, which can't be done by the user. If the > device is not bound to vfio-pci, we have no way of knowing if it belongs to > this or that IOMMU group. iommu groups already exist before vfio-pci is loaded. The whole setup process as described in the VFIO documentation, where a PCIe device shares an iommu group with other devices, can therefore be automated. Some time ago I wrote a ruby script that does exactly that (https://github.com/andre-richter/rVFIO/blob/master/example/pci-bind.rb). Porting it to bash should be no problem. However, the question is if dpdk needs to cover this (corner?) case. I would assume that the bulk of dpdk use-cases deals with scenarios where the targeted NIC is the only one in its iommu group, because it is a high-speed NIC that is connected to a CPU-integrated PCIe-Port. A NIC sharing an iommu group with other devices would be most likely if it is behind a bridge, aka a chipset-integrated NIC or a NIC that resides in a PCIe-Slot that connects to the chipset. This is more common in desktop machines than in server grade machines. Cheers, Andre > > Regarding 2), as noted above, the administrator should set up VFIO devices. > While I agree that the way setup.sh sets up VFIO security permissions is not > ideal, it's really there to cover the most common use case. An administrator > can always set up VFIO on his own, granting permissions as needed. > > Thanks, > Anatoly
[dpdk-dev] VFIO in setup.sh
> iommu groups already exist before vfio-pci is loaded. > The whole setup process as described in the VFIO documentation, where a > PCIe device shares an iommu group with other devices, can therefore be > automated. Some time ago I wrote a ruby script that does exactly that > (https://github.com/andre-richter/rVFIO/blob/master/example/pci- > bind.rb). > Porting it to bash should be no problem. Makes sense to me. Maybe we could output a warning if not all devices in a group were bound to vfio-pci (and possibly list all devices that aren't bound)? IMO, the right place for such a warning would probably be dpdk_nic_bind.py though, not setup.sh. > However, the question is if dpdk needs to cover this (corner?) case. > I would assume that the bulk of dpdk use-cases deals with scenarios where > the targeted NIC is the only one in its iommu group, because it is a high- > speed NIC that is connected to a CPU-integrated PCIe-Port. > A NIC sharing an iommu group with other devices would be most likely if it is > behind a bridge, aka a chipset-integrated NIC or a NIC that resides in a PCIe- > Slot that connects to the chipset. This is more common in desktop machines > than in server grade machines. If no other devices need to be unbound, no warnings, and no harm done :) Thanks, Anatoly
[dpdk-dev] issues with packets bigger than 1500 bytes
Hi again, I tried setting MTU to larger value and I get really weird behaviour - statistics now show that there are no more errors, but after just a few minutes I get a segfault while calling rte_pktmbuf_free(): #0 0x004202fc in rte_atomic16_add_return (v=0xff94, inc=-1) at /opt/dpdk-1.8.0/build/include/generic/rte_atomic.h:247 247 return __sync_add_and_fetch(&v->cnt, inc); (gdb) bt #0 0x004202fc in rte_atomic16_add_return (v=0xff94, inc=-1) at /opt/dpdk-1.8.0/build/include/generic/rte_atomic.h:247 #1 0x00420414 in rte_mbuf_refcnt_update (m=0xff80, value=-1) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:371 #2 0x004205e4 in __rte_pktmbuf_prefree_seg (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:770 #3 rte_pktmbuf_free_seg (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:793 #4 rte_pktmbuf_free (m=0x7f773ff1ce80) at /opt/dpdk-1.8.0/build/include/rte_mbuf.h:816 Is there any reason why changing MTU would cause this? With packets smaller than 1500 bytes and standard MTU, application is stable and there are no problems with calls to rte_pktmbuf_free(). Application is also stable with packets larger than 1500 bytes and standard MTU, but as I said, there are a lot of received errors. BR, Newman On Mon, Mar 30, 2015 at 12:52:22PM +0200, Newman Poborsky wrote: > Hi, > > I'm having some problems with dpdk on links that have packets bigger > than 1500bytes. Some packets that are receieved are around 4K, and > some are 9k jumbo frames. > > When using testpmd app, I can see a lot of RX-errors (both RX-missed and > RX-badlen). When I set max packet length to 9000, RX-badlen counter stops > increasing, but RX-missed still keeps growing. > > What is the proper way to deal with jumbo frames? > > I tried setting MTU to 9k, but this fails. From what I can see, you have to > pass additional parameter to mp_init callback in rte_mempool_create(). Is > this right? > > I'm not sure should I just set max packet length (like in testpmd example > app), or should I (also) set MTU? Is this actually related to the original > problem of having a lot of RX-missed packets? > > If I missed some documentation related to jumbo frames and MTU, I apologize, > please point me to it. > > Any help is appreciated. > > Thank you, > > Newman P.
[dpdk-dev] Question about images in the docs
Hi Bernard, If you get a break during your training could you drop up to me or I can drop down to you. I have a quick question about how the images are template in the docs. John > -Original Message- > From: Mcnamara, John > Sent: Tuesday, March 31, 2015 12:34 PM > To: Thomas Monjalon; Butler, Siobhan A; Iremonger, Bernard > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, March 31, 2015 12:38 AM > > To: Butler, Siobhan A > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > > 2015-03-19 17:48, Thomas Monjalon: > > > Too many things are included in the programmers guide. > > > I think it should cover only API and knowledge needed to make an > > application. > > > That's why I suggest to move Xen and NICs doc outside. > > > Then it will be easier to add doc for a new environment or a new NIC. > > > Note that drivers or device-related libs like KNI, vhost or bonding > > > stay in the programmer's guide because they are more high-level than > > NICs drivers. > > > > > > Changes in v2: > > > - create index for Xen guide > > > - rename figure links > > > - rebase with mlx4 > > > - HTML copyright removal has been sent separately > > > > > > Thomas Monjalon (3): > > > doc: fix file attributes > > > doc: move Xen guide out of programmers guide > > > doc: nics guide > > > > Applied with figures list restored on Bernard's request. > > Hi, > > Any objection to an additional patch to move the figure captions below the > figures in the docs? > > The caption above the figure was the format used in the initial docs, and > it looks okay in the HTML output, but in the PDF output it tends to get > merged into the preceding paragraph and isn't always on the same page as > the figure. > > John > > >
[dpdk-dev] Build failure in v2.0.0-rc3 with !CC_AVX2_SUPPORT
I'm getting errors when building DPDK in an Ubuntu 15.04 VM with T=x86_64-native-linuxapp-gcc. I've got a small VM set up without avx2 in the cpu flags: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 2.0.0 stepping: 3 microcode : 0x1 cpu MHz : 2993.068 cache size : 4096 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl pni vmx cx16 x2apic popcnt hypervisor lahf_lm abm vnmi ept bugs: bogomips: 5986.13 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: In this environment I'm getting a number of build failures such as this one (full build log below): /usr/lib/gcc/x86_64-linux-gnu/4.9/include/tmmintrin.h:185:1: error: inlining failed in call to always_inline ?_mm_alignr_epi8?: target specific option mismatch I can build successfully in an environment with avx2 in the cpu flags. Thanks, Seth --- == Build lib == Build lib/librte_compat SYMLINK-FILE include/rte_compat.h == Build lib/librte_eal == Build lib/librte_eal/common SYMLINK-FILE include/generic/rte_atomic.h SYMLINK-FILE include/generic/rte_byteorder.h SYMLINK-FILE include/generic/rte_cycles.h SYMLINK-FILE include/generic/rte_prefetch.h SYMLINK-FILE include/generic/rte_spinlock.h SYMLINK-FILE include/generic/rte_memcpy.h SYMLINK-FILE include/generic/rte_cpuflags.h SYMLINK-FILE include/rte_branch_prediction.h SYMLINK-FILE include/rte_common.h SYMLINK-FILE include/rte_debug.h SYMLINK-FILE include/rte_eal.h SYMLINK-FILE include/rte_errno.h SYMLINK-FILE include/rte_launch.h SYMLINK-FILE include/rte_lcore.h SYMLINK-FILE include/rte_log.h SYMLINK-FILE include/rte_memory.h SYMLINK-FILE include/rte_memzone.h SYMLINK-FILE include/rte_pci.h SYMLINK-FILE include/rte_pci_dev_ids.h SYMLINK-FILE include/rte_per_lcore.h SYMLINK-FILE include/rte_random.h SYMLINK-FILE include/rte_rwlock.h SYMLINK-FILE include/rte_tailq.h SYMLINK-FILE include/rte_interrupts.h SYMLINK-FILE include/rte_alarm.h SYMLINK-FILE include/rte_string_fns.h SYMLINK-FILE include/rte_version.h SYMLINK-FILE include/rte_eal_memconfig.h SYMLINK-FILE include/rte_malloc_heap.h SYMLINK-FILE include/rte_hexdump.h SYMLINK-FILE include/rte_devargs.h SYMLINK-FILE include/rte_dev.h SYMLINK-FILE include/rte_pci_dev_feature_defs.h SYMLINK-FILE include/rte_pci_dev_features.h SYMLINK-FILE include/rte_memcpy.h SYMLINK-FILE include/rte_cycles.h SYMLINK-FILE include/rte_spinlock.h SYMLINK-FILE include/rte_atomic_32.h SYMLINK-FILE include/rte_vect.h SYMLINK-FILE include/rte_prefetch.h SYMLINK-FILE include/rte_byteorder_32.h SYMLINK-FILE include/rte_atomic_64.h SYMLINK-FILE include/rte_cpuflags.h SYMLINK-FILE include/rte_byteorder_64.h SYMLINK-FILE include/rte_atomic.h SYMLINK-FILE include/rte_byteorder.h == Build lib/librte_eal/linuxapp == Build lib/librte_eal/linuxapp/igb_uio LD /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/built-in.o CC [M] /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o (cat /dev/null; echo kernel//home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/modules.order Building modules, stage 2. MODPOST 1 modules CC /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.mod.o LD [M] /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko INSTALL-MODULE igb_uio.ko == Build lib/librte_eal/linuxapp/eal CC eal.o CC eal_hugepage_info.o CC eal_memory.o CC eal_thread.o CC eal_log.o CC eal_pci.o CC eal_pci_uio.o CC eal_pci_vfio.o CC eal_pci_vfio_mp_sync.o CC eal_debug.o CC eal_lcore.o CC eal_timer.o CC eal_interrupts.o CC eal_alarm.o CC eal_common_memzone.o CC eal_common_log.o CC eal_common_launch.o CC eal_common_pci.o CC eal_common_memory.o CC eal_common_tailqs.o CC eal_common_errno.o CC eal_common_cpuflags.o CC eal_common_string_fns.o CC eal_common_hexdump.o CC eal_common_devargs.o CC eal_common_dev.o CC eal_common_options.o In file included from /usr/lib/gcc/x86_64-linux-gnu/4.9/include/x86intrin.h:37:0, from /home/ubuntu/dpdk/build/include/rte_vect.h:67, from /home/ubuntu/dpdk/build/include/rte_memcpy.h:46, from /home/ubuntu/dpdk/lib/librte_eal/common/eal_common_options.c:48: /home/ubuntu/dpdk/build/include/rte_memcpy.h: In function ?rte_memcpy?: /usr/lib/gcc/x8
[dpdk-dev] Build failure in v2.0.0-rc3 with !CC_AVX2_SUPPORT
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Seth Forshee > Sent: Tuesday, March 31, 2015 3:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Build failure in v2.0.0-rc3 with !CC_AVX2_SUPPORT > > I'm getting errors when building DPDK in an Ubuntu 15.04 VM with > T=x86_64-native-linuxapp-gcc. I've got a small VM set up without avx2 in > the cpu flags: > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 6 > model name : QEMU Virtual CPU version 2.0.0 > stepping: 3 > microcode : 0x1 > cpu MHz : 2993.068 > cache size : 4096 KB > physical id : 0 > siblings: 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 4 > wp : yes > flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov > pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl > pni vmx cx16 x2apic popcnt hypervisor lahf_lm abm vnmi ept It seems that your VM cpu doesn't even have SSE3. As I remember, DPDK doesn't support architectures prior to SSE3, i.e you need a VM with at least core2 CPU. > bugs: > bogomips: 5986.13 > clflush size: 64 > cache_alignment : 64 > address sizes : 40 bits physical, 48 bits virtual > power management: > > In this environment I'm getting a number of build failures such as this > one (full build log below): > > /usr/lib/gcc/x86_64-linux-gnu/4.9/include/tmmintrin.h:185:1: error: > inlining failed in call to always_inline ?_mm_alignr_epi8?: target > specific option mismatch > > I can build successfully in an environment with avx2 in the cpu flags. > > Thanks, > Seth > > --- > > == Build lib > == Build lib/librte_compat > SYMLINK-FILE include/rte_compat.h > == Build lib/librte_eal > == Build lib/librte_eal/common > SYMLINK-FILE include/generic/rte_atomic.h > SYMLINK-FILE include/generic/rte_byteorder.h > SYMLINK-FILE include/generic/rte_cycles.h > SYMLINK-FILE include/generic/rte_prefetch.h > SYMLINK-FILE include/generic/rte_spinlock.h > SYMLINK-FILE include/generic/rte_memcpy.h > SYMLINK-FILE include/generic/rte_cpuflags.h > SYMLINK-FILE include/rte_branch_prediction.h > SYMLINK-FILE include/rte_common.h > SYMLINK-FILE include/rte_debug.h > SYMLINK-FILE include/rte_eal.h > SYMLINK-FILE include/rte_errno.h > SYMLINK-FILE include/rte_launch.h > SYMLINK-FILE include/rte_lcore.h > SYMLINK-FILE include/rte_log.h > SYMLINK-FILE include/rte_memory.h > SYMLINK-FILE include/rte_memzone.h > SYMLINK-FILE include/rte_pci.h > SYMLINK-FILE include/rte_pci_dev_ids.h > SYMLINK-FILE include/rte_per_lcore.h > SYMLINK-FILE include/rte_random.h > SYMLINK-FILE include/rte_rwlock.h > SYMLINK-FILE include/rte_tailq.h > SYMLINK-FILE include/rte_interrupts.h > SYMLINK-FILE include/rte_alarm.h > SYMLINK-FILE include/rte_string_fns.h > SYMLINK-FILE include/rte_version.h > SYMLINK-FILE include/rte_eal_memconfig.h > SYMLINK-FILE include/rte_malloc_heap.h > SYMLINK-FILE include/rte_hexdump.h > SYMLINK-FILE include/rte_devargs.h > SYMLINK-FILE include/rte_dev.h > SYMLINK-FILE include/rte_pci_dev_feature_defs.h > SYMLINK-FILE include/rte_pci_dev_features.h > SYMLINK-FILE include/rte_memcpy.h > SYMLINK-FILE include/rte_cycles.h > SYMLINK-FILE include/rte_spinlock.h > SYMLINK-FILE include/rte_atomic_32.h > SYMLINK-FILE include/rte_vect.h > SYMLINK-FILE include/rte_prefetch.h > SYMLINK-FILE include/rte_byteorder_32.h > SYMLINK-FILE include/rte_atomic_64.h > SYMLINK-FILE include/rte_cpuflags.h > SYMLINK-FILE include/rte_byteorder_64.h > SYMLINK-FILE include/rte_atomic.h > SYMLINK-FILE include/rte_byteorder.h > == Build lib/librte_eal/linuxapp > == Build lib/librte_eal/linuxapp/igb_uio > LD > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/built-in.o > CC [M] > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o > (cat /dev/null; echo > kernel//home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > > > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/modules.order > Building modules, stage 2. > MODPOST 1 modules > CC > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.mod.o > LD [M] > /home/ubuntu/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko > INSTALL-MODULE igb_uio.ko > == Build lib/librte_eal/linuxapp/eal > CC eal.o > CC eal_hugepage_info.o > CC eal_memory.o > CC eal_thread.o > CC eal_log.o > CC eal_pci.o > CC eal_pci_uio.o > CC eal_pci_vfio.o > CC eal_pci_vfio_mp_sync.o > CC eal_debug.o > CC eal_lcore.o > CC eal_timer.o > CC eal_interrupts.o > CC eal_alarm.o > CC eal_common_memzone.o > CC eal_common_log.o > CC eal_
[dpdk-dev] Queries on dpdk buffer allocation and kni
Dear Group members, I have been trying to understand the dpdk code and have got two queries. 1. descriptor rings and packet buffer allocation Looking at the linux native e1000 kernel driver, Memory for NIC's tx and rx descriptor rings are allocated using dma_alloc_coherent. Memory for rx packet buffers are allocated using netdev_alloc_skb and dma address (after dma_map_single) of skb->data is set to rx descriptor to receive packet onto skb. Looking at dpdk user space driver, all rings and packet allocation is done using (dpdk) mem pools. I would like to know a) whether the mem pool internally uses dma_alloc_coherent like apis to allocate buffers b) if the buffer is allocated by kernel, how does the user space application map them and access the packet data directly. 2. kni what is the internal mechanism used to implement FIFO-based shared memory (used between kernel and user-land). Thanks in advance, Rajasekhar
[dpdk-dev] Build failure in v2.0.0-rc3 with !CC_AVX2_SUPPORT
On Tue, Mar 31, 2015 at 02:59:36PM +, Ananyev, Konstantin wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Seth Forshee > > Sent: Tuesday, March 31, 2015 3:41 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Build failure in v2.0.0-rc3 with !CC_AVX2_SUPPORT > > > > I'm getting errors when building DPDK in an Ubuntu 15.04 VM with > > T=x86_64-native-linuxapp-gcc. I've got a small VM set up without avx2 in > > the cpu flags: > > > > $ cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 6 > > model name : QEMU Virtual CPU version 2.0.0 > > stepping: 3 > > microcode : 0x1 > > cpu MHz : 2993.068 > > cache size : 4096 KB > > physical id : 0 > > siblings: 1 > > core id : 0 > > cpu cores : 1 > > apicid : 0 > > initial apicid : 0 > > fpu : yes > > fpu_exception : yes > > cpuid level : 4 > > wp : yes > > flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca > > cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl > > pni vmx cx16 x2apic popcnt hypervisor lahf_lm abm vnmi ept > > > It seems that your VM cpu doesn't even have SSE3. > As I remember, DPDK doesn't support architectures prior to SSE3, i.e you need > a VM with at least core2 CPU. This VM was set up with a script that just uses the qemu default CPU, which is quite basic. Bumping it up to a core2 with SSE3 but not avx does get the build working. So if that CPU lacks features required by DPDK then I guess there's no problem, I just didn't know how to interpret those build errors. Thanks, Seth
[dpdk-dev] [PATCH] mbuf: clean old refcnt option
CONFIG_RTE_MBUF_SCATTER_GATHER was renamed into CONFIG_RTE_MBUF_REFCNT
by commit 62814bc2e923 and removed by commit 4769bc5a27cc.
Some traces remain because of delayed patches.
It can also be removed from doxygen config.
It is now poisoned in rte_mbuf.h to warn any misuse.
Fixes: d0dff9ba445e ("doc: sample application user guide")
Fixes: fc1f2750a3ec ("doc: programmers guide")
Fixes: 4769bc5a27cc ("mbuf: remove build option to disable refcnt")
Signed-off-by: Thomas Monjalon
---
doc/api/doxy-api.conf | 3 +--
doc/guides/nics/ixgbe.rst | 2 --
.../prog_guide/ip_fragment_reassembly_lib.rst | 1 -
doc/guides/sample_app_ug/vhost.rst | 22 --
lib/librte_ether/rte_ether.h | 3 +--
lib/librte_mbuf/rte_mbuf.h | 3 ++-
6 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index 5a71a76..da03e9b 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -59,8 +59,7 @@ INPUT = doc/api/doxy-api-index.md \
FILE_PATTERNS = rte_*.h \
cmdline.h
PREDEFINED = __DOXYGEN__ \
- __attribute__(x)= \
- RTE_MBUF_REFCNT
+ __attribute__(x)=
OPTIMIZE_OUTPUT_FOR_C = YES
ENABLE_PREPROCESSING= YES
diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
index d2c124e..70cd591 100644
--- a/doc/guides/nics/ixgbe.rst
+++ b/doc/guides/nics/ixgbe.rst
@@ -168,8 +168,6 @@ When CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=y, better
performance can be achieved:
./x86_64-native-linuxapp-gcc/app/testpmd -c 300 -n 4 -- -i --burst=32
--rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32
--txqflags=0xf01 --disable-hw-vlan
-If scatter gather lists are not required, set CONFIG_RTE_MBUF_SCATTER_GATHER=n
for better throughput.
-
l3fwd
^
diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
index d17daa7..7d6bdaa 100644
--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
@@ -54,7 +54,6 @@ Finally 'direct' and 'indirect' mbufs for each fragnemt are
linked together via
The caller has an ability to explicitly specify which mempools should be used
to allocate 'direct' and 'indirect' mbufs from.
-Note that configuration macro RTE_MBUF_SCATTER_GATHER has to be enabled to
make fragmentation library build and work correctly.
For more information about direct and indirect mbufs, refer to the *DPDK
Programmers guide 7.7 Direct and Indirect Buffers.*
Packet reassembly
diff --git a/doc/guides/sample_app_ug/vhost.rst
b/doc/guides/sample_app_ug/vhost.rst
index cd9b232..8a7eb3b 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -338,28 +338,6 @@ Compiling the Sample Code
.. code-block:: console
-make
-
-.. note::
-
-Note For zero copy, need firstly disable
CONFIG_RTE_MBUF_SCATTER_GATHER,
-CONFIG_RTE_LIBRTE_IP_FRAG and CONFIG_RTE_LIBRTE_DISTRIBUTOR
-in the config file and then re-configure and compile the core lib, and
then build the application:
-
-.. code-block:: console
-
-vi ${RTE_SDK}/config/common_linuxapp
-
-change it as follows:
-
-::
-
-CONFIG_RTE_MBUF_SCATTER_GATHER=n
-CONFIG_RTE_LIBRTE_IP_FRAG=n
-CONFIG_RTE_LIBRTE_DISTRIBUTOR=n
-
-.. code-block:: console
-
cd ${RTE_SDK}
make config ${RTE_TARGET}
make install ${RTE_TARGET}
diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
index bafeb2b..49f4576 100644
--- a/lib/librte_ether/rte_ether.h
+++ b/lib/librte_ether/rte_ether.h
@@ -383,7 +383,6 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
struct ether_hdr *oh, *nh;
struct vlan_hdr *vh;
-#ifdef RTE_MBUF_REFCNT
/* Can't insert header if mbuf is shared */
if (rte_mbuf_refcnt_read(*m) > 1) {
struct rte_mbuf *copy;
@@ -394,7 +393,7 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
rte_pktmbuf_free(*m);
*m = copy;
}
-#endif
+
oh = rte_pktmbuf_mtod(*m, struct ether_hdr *);
nh = (struct ether_hdr *)
rte_pktmbuf_prepend(*m, sizeof(struct vlan_hdr));
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 0265172..45f73c2 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -64,8 +64,9 @@
extern "C" {
#endif
-/* deprecated feature, renamed in RTE_MBUF_REFCNT */
+/* deprecated options */
#pragma GCC poison RTE_MBUF_SCATTER_GATHER
+#pragma GCC poison RTE_MBUF_REFCNT
/*
* Packet Offload Features Flags. It also carry packet type information.
--
2.2.2
[dpdk-dev] dev@DPDK Hackathon Proposal
Hi all, As a community we have virtually come together from all over the globe, developing now our third successful open source DPDK version with DPDK r2.0 about to release. It is astounding to comprehend the commitment and enthusiasm you have all shared to bring DPDK to this point. With growing the community of developers in mind, and strengthening the networks and virtual collaborations that have come about, I propose that we hold the first dev at DPDK Developer Hackathon this year. Many people will be travelling to Dublin, Ireland for LinuxCon and CloudOpen October (5th-7th). I propose that we hold a hands on 2 day hackathon Thursday October 8th and Friday October 9th to coincide with this offering, in Dublin. >From a community perspective is a great opportunity to bring together the >people that make DPDK happen - the developers. >From a developer perspective it is a great opportunity to be part of the first >gathering, meet some new people, learn something new and have a lot of fun on the way. At this point the agenda is open - so if you see merit in this proposal please share your interest here so that we can gauge attendance and gather ideas of what people would like the format to be. Thanks, Siobhan
[dpdk-dev] [PATCH v4 0/7] Move EAL common function
I will work on it and send out patches by next week. If you need it earlier please let me know. Thanks, Ravi On Mon, Mar 30, 2015 at 4:24 PM, Thomas Monjalon wrote: > 2015-03-30 16:15, Ravi Kerur: > > On Mon, Mar 30, 2015 at 2:29 PM, Thomas Monjalon < > thomas.monjalon at 6wind.com> wrote: > > > Sorry for not integrating this big refactoring in release 2.0. > > > It wasn't easy to merge it during development of some EAL features. > > > And it's now too risky to rework it before the release. > > > I think this clean-up is needed and should be done at the beginning of > 2.1 > > > cycle. We just need to rebase it and remove the "ifdef BSD/LINUX" > which was > > > introduced in pci code. > > > > > > Do you think you'll have time for it? > > > > Sure, please let me know when it is needed I can work on it. > > 2.1 cycle is starting in few days. > So the sooner is the better. > > Thanks a lot Ravi >
[dpdk-dev] [PATCH v2 1/5] mbuf: fix clone support when application uses private mbuf data
Hi Konstantin,
On 03/31/2015 01:17 AM, Ananyev, Konstantin wrote:
With this solution, there are 2 options:
- no mempool modification, so each application/driver has to add
priv_size bytes to the object to get the mbuf pointer. This does not
look feasible.
- change the mempool to support private area before each object. I
think mempool API is already quite complex, and I think it's not
the role of the mempool library to provide such features.
>>>
>>>
>>> In fact, I think the changes would be minimal.
>>> All we have to do, is to make changes in rte_pktmbuf_init():
>>>
>>> void
>>> rte_pktmbuf_init(struct rte_mempool *mp,
>>> __attribute__((unused)) void *opaque_arg,
>>> void *_m,
>>> __attribute__((unused)) unsigned i)
>>> {
>>>
>>> //extract priv_size from mempool (discussed above).
>>> uint16_t priv_size = rte_mbufpool_get_priv_size(mp);
>>>
>>> struct rte_mbuf *m = _m + priv_size;
>>> uint32_t buf_len = mp->elt_size - sizeof(struct rte_mbuf) - priv_size;
>>>
>>>
>>>
>>>
>>> With that way priv_size inside mbuf would always be the size its own
>>> private space,
>>> for both direct and indirect mbus., so we don't require to set priv_size at
>>> attach/detach.
>>> Again RTE_MBUF_TO_BADDR() and RTE_MBUF_FROM_BADDR() would just work without
>>> any modifications.
>>
>> I'm not sure I'm getting it. The argument '_m' of your
>> rte_pktmbuf_init() is the pointer to the priv data, right?
>> So it means that the mbuf is located priv_size bytes after.
>>
>> The rte_pktmbuf_init() function is called by mempool_create(),
>> and the _m parameter is a pointer to a mempool object. So
>> in my understanding, mempool_get() would not return a rte_mbuf
>> but a pointer to the application private data.
>
> Ah my bad, forgot that mempool's obj_init() returns void now :(
> To make this approach work also need to change it, so it return a pointer to
> the new object.
> So, rte_pktmbuf_init() would return m and then in mempool_add_elem():
>
> if (obj_init)
> obj = obj_init(mp, obj_init_arg, obj, obj_idx);
>
> rte_ring_sp_enqueue(mp->ring, obj);
Yes, but modififying mempool is what I wanted to avoid for several
reasons. First, I think that changing the mempool_create() API here
(actually the obj_init prototype) would impact existing applications.
Also, I'm afraid that storing a different address than the start
address of the object would have additional impacts. For instance,
some data is supposed to be stored before the object, see
__mempool_from_obj() or mempool_obj_audit().
Finally, I believe that mempool is not the proper place to do
modifications that are only needed for mbufs. If we really want
to implement mbuf private data in that way, maybe it would be
better to add a new layer above mempool (a mbuf pool layer).
Regards
Olivier
[dpdk-dev] [PATCH v3 0/5] mbuf: enhancements of mbuf clones
This series fixes the support of indirect mbufs when the application reserves a private area in mbufs. This is done adding a new field in each mbuf storing the size of this private area. Another option would have been to store that in the mbuf pool private info, but as we have enough room in mbuf, it's faster to have it in the mbuf. The series also removes the limitation that rte_pktmbuf_clone() is only allowed on direct (non-cloned) mbufs. Changes in v3: - a mbuf can now attach to another one that have a different private size. In this case, the m->priv_size corresponds to the size of the private area of the direct mbuf. - add comments to reflect these changes - minor style modifications Changes in v2: - do not change the use of MBUF_EXT_MEM() in vhost - change rte_mbuf_from_baddr() to rte_mbuf_from_indirect(), removing one parameter - fix and rework rte_pktmbuf_detach() - move m->priv_size in second mbuf cache line - fix mbuf free in test error case Olivier Matz (5): mbuf: fix clone support when application uses private mbuf data mbuf: allow to clone an indirect mbuf test/mbuf: rename mc variable in m test/mbuf: enhance mbuf refcnt test test/mbuf: verify that cloning a clone works properly app/test-pmd/testpmd.c | 1 + app/test/test_mbuf.c | 88 +++- examples/vhost/main.c | 4 +- lib/librte_mbuf/rte_mbuf.c | 1 + lib/librte_mbuf/rte_mbuf.h | 123 +++-- 5 files changed, 164 insertions(+), 53 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH v3 1/5] mbuf: fix clone support when application uses private mbuf data
From: Olivier Matz
Add a new private_size field in mbuf structure that should
be initialized at mbuf pool creation. This field contains the
size of the application private data in mbufs.
Introduce new static inline functions rte_mbuf_from_indirect()
and rte_mbuf_to_baddr() to replace the existing macros, which
take the private size in account when attaching and detaching
mbufs.
Signed-off-by: Olivier Matz
---
app/test-pmd/testpmd.c | 1 +
examples/vhost/main.c | 4 +--
lib/librte_mbuf/rte_mbuf.c | 1 +
lib/librte_mbuf/rte_mbuf.h | 77 +++---
4 files changed, 63 insertions(+), 20 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 3057791..c5a195a 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -425,6 +425,7 @@ testpmd_mbuf_ctor(struct rte_mempool *mp,
mb->tx_offload = 0;
mb->vlan_tci = 0;
mb->hash.rss = 0;
+ mb->priv_size= 0;
}
static void
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index c3fcb80..e44e82f 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -139,7 +139,7 @@
/* Number of descriptors per cacheline. */
#define DESC_PER_CACHELINE (RTE_CACHE_LINE_SIZE / sizeof(struct vring_desc))
-#define MBUF_EXT_MEM(mb) (RTE_MBUF_FROM_BADDR((mb)->buf_addr) != (mb))
+#define MBUF_EXT_MEM(mb) (rte_mbuf_from_indirect(mb) != (mb))
/* mask of enabled ports */
static uint32_t enabled_port_mask = 0;
@@ -1550,7 +1550,7 @@ attach_rxmbuf_zcp(struct virtio_net *dev)
static inline void pktmbuf_detach_zcp(struct rte_mbuf *m)
{
const struct rte_mempool *mp = m->pool;
- void *buf = RTE_MBUF_TO_BADDR(m);
+ void *buf = rte_mbuf_to_baddr(m);
uint32_t buf_ofs;
uint32_t buf_len = mp->elt_size - sizeof(*m);
m->buf_physaddr = rte_mempool_virt2phy(mp, m) + sizeof(*m);
diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
index 526b18d..e095999 100644
--- a/lib/librte_mbuf/rte_mbuf.c
+++ b/lib/librte_mbuf/rte_mbuf.c
@@ -125,6 +125,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
m->pool = mp;
m->nb_segs = 1;
m->port = 0xff;
+ m->priv_size = 0;
}
/* do some sanity checks on a mbuf: panic if it fails */
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 17ba791..932fe58 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -317,18 +317,51 @@ struct rte_mbuf {
/* uint64_t unused:8; */
};
};
+
+ /** Size of the application private data. In case of an indirect
+* mbuf, it stores the direct mbuf private data size. */
+ uint16_t priv_size;
} __rte_cache_aligned;
/**
- * Given the buf_addr returns the pointer to corresponding mbuf.
+ * Return the mbuf owning the data buffer address of an indirect mbuf.
+ *
+ * @param mi
+ * The pointer to the indirect mbuf.
+ * @return
+ * The address of the direct mbuf corresponding to buffer_addr.
*/
-#define RTE_MBUF_FROM_BADDR(ba) (((struct rte_mbuf *)(ba)) - 1)
+static inline struct rte_mbuf *
+rte_mbuf_from_indirect(struct rte_mbuf *mi)
+{
+ struct rte_mbuf *md;
+
+ /* mi->buf_addr and mi->priv_size correspond to buffer and
+ * private size of the direct mbuf */
+ md = (struct rte_mbuf *)((char *)mi->buf_addr - sizeof(*mi) -
+ mi->priv_size);
+ return md;
+}
/**
- * Given the pointer to mbuf returns an address where it's buf_addr
- * should point to.
+ * Return the buffer address embedded in the given mbuf.
+ *
+ * The user must ensure that m->priv_size corresponds to the
+ * private size of this mbuf, which is not the case for indirect
+ * mbufs.
+ *
+ * @param md
+ * The pointer to the mbuf.
+ * @return
+ * The address of the data buffer owned by the mbuf.
*/
-#define RTE_MBUF_TO_BADDR(mb) (((struct rte_mbuf *)(mb)) + 1)
+static inline char *
+rte_mbuf_to_baddr(struct rte_mbuf *md)
+{
+ char *buffer_addr;
+ buffer_addr = (char *)md + sizeof(*md) + md->priv_size;
+ return buffer_addr;
+}
/**
* Returns TRUE if given mbuf is indirect, or FALSE otherwise.
@@ -688,6 +721,7 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct
rte_mempool *mp)
/**
* Attach packet mbuf to another packet mbuf.
+ *
* After attachment we refer the mbuf we attached as 'indirect',
* while mbuf we attached to as 'direct'.
* Right now, not supported:
@@ -701,7 +735,6 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct
rte_mempool *mp)
* @param md
* The direct packet mbuf.
*/
-
static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *md)
{
RTE_MBUF_ASSERT(RTE_MBUF_DIRECT(md) &&
@@ -712,6 +745,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi,
struct rte_mbuf *md)
mi->buf_physaddr = md->buf_physaddr;
mi->buf_addr = md->buf_addr;
mi->buf_len = md->buf_len
[dpdk-dev] [PATCH v3 2/5] mbuf: allow to clone an indirect mbuf
From: Olivier Matz
Remove one limitation of rte_pktmbuf_attach(): "mbuf we're attaching to
must be direct".
Now, when we attach to an indirect mbuf:
- copy the all relevant fields (addr, len, offload, ...) as before
- get the pointer to the mbuf that embeds the data buffer (direct mbuf),
and increase the reference counter of this one.
When detaching the mbuf, we can retrieve this direct mbuf as the pointer
is determined from the buffer address.
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.h | 48 ++
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 932fe58..ca6be88 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -725,44 +725,50 @@ static inline struct rte_mbuf *rte_pktmbuf_alloc(struct
rte_mempool *mp)
* After attachment we refer the mbuf we attached as 'indirect',
* while mbuf we attached to as 'direct'.
* Right now, not supported:
- * - attachment to indirect mbuf (e.g. - md has to be direct).
* - attachment for already indirect mbuf (e.g. - mi has to be direct).
* - mbuf we trying to attach (mi) is used by someone else
*e.g. it's reference counter is greater then 1.
*
* @param mi
* The indirect packet mbuf.
- * @param md
- * The direct packet mbuf.
+ * @param m
+ * The packet mbuf we're attaching to.
*/
-static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *md)
+static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
{
- RTE_MBUF_ASSERT(RTE_MBUF_DIRECT(md) &&
- RTE_MBUF_DIRECT(mi) &&
+ struct rte_mbuf *md;
+
+ RTE_MBUF_ASSERT(RTE_MBUF_DIRECT(mi) &&
rte_mbuf_refcnt_read(mi) == 1);
+ /* if m is not direct, get the mbuf that embeds the data */
+ if (RTE_MBUF_DIRECT(m))
+ md = m;
+ else
+ md = rte_mbuf_from_indirect(m);
+
rte_mbuf_refcnt_update(md, 1);
- mi->buf_physaddr = md->buf_physaddr;
- mi->buf_addr = md->buf_addr;
- mi->buf_len = md->buf_len;
- mi->priv_size = md->priv_size;
-
- mi->next = md->next;
- mi->data_off = md->data_off;
- mi->data_len = md->data_len;
- mi->port = md->port;
- mi->vlan_tci = md->vlan_tci;
- mi->tx_offload = md->tx_offload;
- mi->hash = md->hash;
+ mi->buf_physaddr = m->buf_physaddr;
+ mi->buf_addr = m->buf_addr;
+ mi->buf_len = m->buf_len;
+ mi->priv_size = m->priv_size;
+
+ mi->next = m->next;
+ mi->data_off = m->data_off;
+ mi->data_len = m->data_len;
+ mi->port = m->port;
+ mi->vlan_tci = m->vlan_tci;
+ mi->tx_offload = m->tx_offload;
+ mi->hash = m->hash;
mi->next = NULL;
mi->pkt_len = mi->data_len;
mi->nb_segs = 1;
- mi->ol_flags = md->ol_flags | IND_ATTACHED_MBUF;
- mi->packet_type = md->packet_type;
+ mi->ol_flags = m->ol_flags | IND_ATTACHED_MBUF;
+ mi->packet_type = m->packet_type;
__rte_mbuf_sanity_check(mi, 1);
- __rte_mbuf_sanity_check(md, 0);
+ __rte_mbuf_sanity_check(m, 0);
}
/**
--
2.1.4
[dpdk-dev] [PATCH v3 3/5] test/mbuf: rename mc variable in m
From: Olivier Matz
It's better to name the mbuf 'm' instead of 'mc' as it's not a clone.
Signed-off-by: Olivier Matz
---
app/test/test_mbuf.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 1ff66cb..9a3cf8f 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -321,43 +321,42 @@ fail:
static int
testclone_testupdate_testdetach(void)
{
- struct rte_mbuf *mc = NULL;
+ struct rte_mbuf *m = NULL;
struct rte_mbuf *clone = NULL;
/* alloc a mbuf */
-
- mc = rte_pktmbuf_alloc(pktmbuf_pool);
- if (mc == NULL)
+ m = rte_pktmbuf_alloc(pktmbuf_pool);
+ if (m == NULL)
GOTO_FAIL("ooops not allocating mbuf");
- if (rte_pktmbuf_pkt_len(mc) != 0)
+ if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("Bad length");
/* clone the allocated mbuf */
- clone = rte_pktmbuf_clone(mc, pktmbuf_pool);
+ clone = rte_pktmbuf_clone(m, pktmbuf_pool);
if (clone == NULL)
GOTO_FAIL("cannot clone data\n");
rte_pktmbuf_free(clone);
- mc->next = rte_pktmbuf_alloc(pktmbuf_pool);
- if(mc->next == NULL)
+ m->next = rte_pktmbuf_alloc(pktmbuf_pool);
+ if (m->next == NULL)
GOTO_FAIL("Next Pkt Null\n");
- clone = rte_pktmbuf_clone(mc, pktmbuf_pool);
+ clone = rte_pktmbuf_clone(m, pktmbuf_pool);
if (clone == NULL)
GOTO_FAIL("cannot clone data\n");
/* free mbuf */
- rte_pktmbuf_free(mc);
+ rte_pktmbuf_free(m);
rte_pktmbuf_free(clone);
- mc = NULL;
+ m = NULL;
clone = NULL;
return 0;
fail:
- if (mc)
- rte_pktmbuf_free(mc);
+ if (m)
+ rte_pktmbuf_free(m);
return -1;
}
#undef GOTO_FAIL
--
2.1.4
[dpdk-dev] [PATCH v3 4/5] test/mbuf: enhance mbuf refcnt test
From: Olivier Matz
Check that the data in the cloned mbuf is the same than in the
reference mbuf.
Check that the reference counter is incremented for each segment.
Signed-off-by: Olivier Matz
---
app/test/test_mbuf.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 9a3cf8f..9d8ee4e 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -76,6 +76,8 @@
#define REFCNT_MBUF_SIZE(sizeof (struct rte_mbuf) +
RTE_PKTMBUF_HEADROOM)
#define REFCNT_RING_SIZE(REFCNT_MBUF_NUM * REFCNT_MAX_REF)
+#define MAGIC_DATA 0x42424242
+
#define MAKE_STRING(x) # x
static struct rte_mempool *pktmbuf_pool = NULL;
@@ -323,6 +325,7 @@ testclone_testupdate_testdetach(void)
{
struct rte_mbuf *m = NULL;
struct rte_mbuf *clone = NULL;
+ uint32_t *data;
/* alloc a mbuf */
m = rte_pktmbuf_alloc(pktmbuf_pool);
@@ -332,21 +335,53 @@ testclone_testupdate_testdetach(void)
if (rte_pktmbuf_pkt_len(m) != 0)
GOTO_FAIL("Bad length");
+ rte_pktmbuf_append(m, sizeof(uint32_t));
+ data = rte_pktmbuf_mtod(m, uint32_t *);
+ *data = MAGIC_DATA;
/* clone the allocated mbuf */
clone = rte_pktmbuf_clone(m, pktmbuf_pool);
if (clone == NULL)
GOTO_FAIL("cannot clone data\n");
+
+ data = rte_pktmbuf_mtod(clone, uint32_t *);
+ if (*data != MAGIC_DATA)
+ GOTO_FAIL("invalid data in clone\n");
+
+ if (rte_mbuf_refcnt_read(m) != 2)
+ GOTO_FAIL("invalid refcnt in m\n");
+
+ /* free the clone */
rte_pktmbuf_free(clone);
+ clone = NULL;
+ /* same test with a chained mbuf */
m->next = rte_pktmbuf_alloc(pktmbuf_pool);
if (m->next == NULL)
GOTO_FAIL("Next Pkt Null\n");
+ rte_pktmbuf_append(m->next, sizeof(uint32_t));
+ data = rte_pktmbuf_mtod(m->next, uint32_t *);
+ *data = MAGIC_DATA;
+
clone = rte_pktmbuf_clone(m, pktmbuf_pool);
if (clone == NULL)
GOTO_FAIL("cannot clone data\n");
+ data = rte_pktmbuf_mtod(clone, uint32_t *);
+ if (*data != MAGIC_DATA)
+ GOTO_FAIL("invalid data in clone\n");
+
+ data = rte_pktmbuf_mtod(clone->next, uint32_t *);
+ if (*data != MAGIC_DATA)
+ GOTO_FAIL("invalid data in clone->next\n");
+
+ if (rte_mbuf_refcnt_read(m) != 2)
+ GOTO_FAIL("invalid refcnt in m\n");
+
+ if (rte_mbuf_refcnt_read(m->next) != 2)
+ GOTO_FAIL("invalid refcnt in m->next\n");
+
/* free mbuf */
rte_pktmbuf_free(m);
rte_pktmbuf_free(clone);
@@ -357,6 +392,8 @@ testclone_testupdate_testdetach(void)
fail:
if (m)
rte_pktmbuf_free(m);
+ if (clone)
+ rte_pktmbuf_free(clone);
return -1;
}
#undef GOTO_FAIL
--
2.1.4
[dpdk-dev] [PATCH v3 5/5] test/mbuf: verify that cloning a clone works properly
From: Olivier Matz
Signed-off-by: Olivier Matz
---
app/test/test_mbuf.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 9d8ee4e..e59aedc 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -325,6 +325,7 @@ testclone_testupdate_testdetach(void)
{
struct rte_mbuf *m = NULL;
struct rte_mbuf *clone = NULL;
+ struct rte_mbuf *clone2 = NULL;
uint32_t *data;
/* alloc a mbuf */
@@ -382,11 +383,34 @@ testclone_testupdate_testdetach(void)
if (rte_mbuf_refcnt_read(m->next) != 2)
GOTO_FAIL("invalid refcnt in m->next\n");
+ /* try to clone the clone */
+
+ clone2 = rte_pktmbuf_clone(clone, pktmbuf_pool);
+ if (clone2 == NULL)
+ GOTO_FAIL("cannot clone the clone\n");
+
+ data = rte_pktmbuf_mtod(clone2, uint32_t *);
+ if (*data != MAGIC_DATA)
+ GOTO_FAIL("invalid data in clone2\n");
+
+ data = rte_pktmbuf_mtod(clone2->next, uint32_t *);
+ if (*data != MAGIC_DATA)
+ GOTO_FAIL("invalid data in clone2->next\n");
+
+ if (rte_mbuf_refcnt_read(m) != 3)
+ GOTO_FAIL("invalid refcnt in m\n");
+
+ if (rte_mbuf_refcnt_read(m->next) != 3)
+ GOTO_FAIL("invalid refcnt in m->next\n");
+
/* free mbuf */
rte_pktmbuf_free(m);
rte_pktmbuf_free(clone);
+ rte_pktmbuf_free(clone2);
+
m = NULL;
clone = NULL;
+ clone2 = NULL;
return 0;
fail:
@@ -394,6 +418,8 @@ fail:
rte_pktmbuf_free(m);
if (clone)
rte_pktmbuf_free(clone);
+ if (clone2)
+ rte_pktmbuf_free(clone2);
return -1;
}
#undef GOTO_FAIL
--
2.1.4
[dpdk-dev] [PATCH] mbuf: clean old refcnt option
Hi Thomas,
On 03/31/2015 07:58 PM, Thomas Monjalon wrote:
> CONFIG_RTE_MBUF_SCATTER_GATHER was renamed into CONFIG_RTE_MBUF_REFCNT
> by commit 62814bc2e923 and removed by commit 4769bc5a27cc.
> Some traces remain because of delayed patches.
>
> It can also be removed from doxygen config.
> It is now poisoned in rte_mbuf.h to warn any misuse.
>
> Fixes: d0dff9ba445e ("doc: sample application user guide")
> Fixes: fc1f2750a3ec ("doc: programmers guide")
> Fixes: 4769bc5a27cc ("mbuf: remove build option to disable refcnt")
>
> Signed-off-by: Thomas Monjalon
> ---
> doc/api/doxy-api.conf | 3 +--
> doc/guides/nics/ixgbe.rst | 2 --
> .../prog_guide/ip_fragment_reassembly_lib.rst | 1 -
> doc/guides/sample_app_ug/vhost.rst | 22
> --
> lib/librte_ether/rte_ether.h | 3 +--
> lib/librte_mbuf/rte_mbuf.h | 3 ++-
> 6 files changed, 4 insertions(+), 30 deletions(-)
>
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index 5a71a76..da03e9b 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -59,8 +59,7 @@ INPUT = doc/api/doxy-api-index.md \
> FILE_PATTERNS = rte_*.h \
>cmdline.h
> PREDEFINED = __DOXYGEN__ \
> - __attribute__(x)= \
> - RTE_MBUF_REFCNT
> + __attribute__(x)=
>
> OPTIMIZE_OUTPUT_FOR_C = YES
> ENABLE_PREPROCESSING= YES
> diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst
> index d2c124e..70cd591 100644
> --- a/doc/guides/nics/ixgbe.rst
> +++ b/doc/guides/nics/ixgbe.rst
> @@ -168,8 +168,6 @@ When CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=y, better
> performance can be achieved:
>
> ./x86_64-native-linuxapp-gcc/app/testpmd -c 300 -n 4 -- -i --burst=32
> --rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32
> --txrst=32 --txqflags=0xf01 --disable-hw-vlan
>
> -If scatter gather lists are not required, set
> CONFIG_RTE_MBUF_SCATTER_GATHER=n for better throughput.
> -
> l3fwd
> ^
>
> diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> index d17daa7..7d6bdaa 100644
> --- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> +++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
> @@ -54,7 +54,6 @@ Finally 'direct' and 'indirect' mbufs for each fragnemt are
> linked together via
>
> The caller has an ability to explicitly specify which mempools should be
> used to allocate 'direct' and 'indirect' mbufs from.
>
> -Note that configuration macro RTE_MBUF_SCATTER_GATHER has to be enabled to
> make fragmentation library build and work correctly.
> For more information about direct and indirect mbufs, refer to the *DPDK
> Programmers guide 7.7 Direct and Indirect Buffers.*
>
> Packet reassembly
> diff --git a/doc/guides/sample_app_ug/vhost.rst
> b/doc/guides/sample_app_ug/vhost.rst
> index cd9b232..8a7eb3b 100644
> --- a/doc/guides/sample_app_ug/vhost.rst
> +++ b/doc/guides/sample_app_ug/vhost.rst
> @@ -338,28 +338,6 @@ Compiling the Sample Code
>
> .. code-block:: console
>
> -make
> -
> -.. note::
> -
> -Note For zero copy, need firstly disable
> CONFIG_RTE_MBUF_SCATTER_GATHER,
> -CONFIG_RTE_LIBRTE_IP_FRAG and CONFIG_RTE_LIBRTE_DISTRIBUTOR
> -in the config file and then re-configure and compile the core lib,
> and then build the application:
> -
> -.. code-block:: console
> -
> -vi ${RTE_SDK}/config/common_linuxapp
> -
> -change it as follows:
> -
> -::
> -
> -CONFIG_RTE_MBUF_SCATTER_GATHER=n
> -CONFIG_RTE_LIBRTE_IP_FRAG=n
> -CONFIG_RTE_LIBRTE_DISTRIBUTOR=n
> -
> -.. code-block:: console
> -
> cd ${RTE_SDK}
> make config ${RTE_TARGET}
> make install ${RTE_TARGET}
> diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
> index bafeb2b..49f4576 100644
> --- a/lib/librte_ether/rte_ether.h
> +++ b/lib/librte_ether/rte_ether.h
> @@ -383,7 +383,6 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
> struct ether_hdr *oh, *nh;
> struct vlan_hdr *vh;
>
> -#ifdef RTE_MBUF_REFCNT
> /* Can't insert header if mbuf is shared */
> if (rte_mbuf_refcnt_read(*m) > 1) {
> struct rte_mbuf *copy;
> @@ -394,7 +393,7 @@ static inline int rte_vlan_insert(struct rte_mbuf **m)
> rte_pktmbuf_free(*m);
> *m = copy;
> }
> -#endif
> +
> oh = rte_pktmbuf_mtod(*m, struct ether_hdr *);
> nh = (struct ether_hdr *)
> rte_pktmbuf_prepend(*m, sizeof(struct vlan_hdr));
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 0265172..45f73c2 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf
