[dpdk-users] users Digest, Vol 155, Issue 7

waqas ahmed waqasahmed1471 at gmail.com
Fri Oct 12 14:40:01 CEST 2018


i think you are increasing descriptors to keep it like FIFO after 2
seconds, that isnt necessary. you need large amount of main memory from
where you allocate appropriate number of huge pages to the dpdk app. you
can do some calculation with size of mbuf and have 28 million mbufs for 2
seconds.
once 512 descriptors are exhausted than old ones are replaced with new
pointer every time it receives a packet and mbuf is allocated from the pool
if available.

On Fri, Oct 12, 2018 at 3:00 PM <users-request at dpdk.org> wrote:

> Send users mailing list submissions to
>         users at dpdk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mails.dpdk.org/listinfo/users
> or, via email, send a message with subject or body 'help' to
>         users-request at dpdk.org
>
> You can reach the person managing the list at
>         users-owner at dpdk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>    1. Re: Problems compiling DPDK for MLX4 (Anthony Hart)
>    2. Increasing the NB_MBUFs of PktMbuf MemPool (Wajeeha Javed)
>    3. Re: Increasing the NB_MBUFs of PktMbuf MemPool (Andrew Rybchenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Oct 2018 16:21:48 -0400
> From: Anthony Hart <ahart at domainhart.com>
> To: Cliff Burdick <shaklee3 at gmail.com>
> Cc: users <users at dpdk.org>
> Subject: Re: [dpdk-users] Problems compiling DPDK for MLX4
> Message-ID: <B10CCD14-3255-499B-99B0-4D92E6EF8CE4 at domainhart.com>
> Content-Type: text/plain;       charset=utf-8
>
> Thanks I will try that
>
> > On Oct 11, 2018, at 3:11 PM, Cliff Burdick <shaklee3 at gmail.com> wrote:
> >
> > The easy workaround is to install the mellanox OFED package with the
> flags --dpdk --upstream-libs.
> >
> > On Thu, Oct 11, 2018 at 8:57 AM Anthony Hart <ahart at domainhart.com
> <mailto:ahart at domainhart.com>> wrote:
> >
> > Having problems compiling DPDK for the Mellanox PMD.
> >
> > For dpdk-18-08 I get...
> >
> >   CC efx_phy.o
> > In file included from
> /root/th/dpdk-18.08/drivers/net/mlx4/mlx4_txq.c:35:0:
> > /root/th/dpdk-18.08/drivers/net/mlx4/mlx4_glue.h:16:31: fatal error:
> infiniband/mlx4dv.h: No such file or directory
> >  #include <infiniband/mlx4dv.h>
> >                                ^
> > compilation terminated.
> > In file included from
> /root/th/dpdk-18.08/drivers/net/mlx4/mlx4_intr.c:32:0:
> > /root/th/dpdk-18.08/drivers/net/mlx4/mlx4_glue.h:16:31: fatal error:
> infiniband/mlx4dv.h: No such file or directory
> >  #include <infiniband/mlx4dv.h>
> >
> >
> > For dpdk-1711.3
> >
> >   CC mlx5.o
> > /root/th/dpdk-stable-17.11.3/drivers/net/mlx5/mlx5.c: In function
> ?mlx5_pci_probe?:
> > /root/th/dpdk-stable-17.11.3/drivers/net/mlx5/mlx5.c:921:21: error:
> ?struct ibv_device_attr_ex? has no member named ?device_cap_flags_ex?
> >     !!(device_attr_ex.device_cap_flags_ex &
> >                      ^
> > /root/th/dpdk-stable-17.11.3/drivers/net/mlx5/mlx5.c:922:7: error:
> ?IBV_DEVICE_RAW_IP_CSUM? undeclared (first use in this function)
> >        IBV_DEVICE_RAW_IP_CSUM);
> >        ^
> > /root/th/dpdk-stable-17.11.3/drivers/net/mlx5/mlx5.c:922:7: note: each
> undeclared identifier is reported only once for each function it appears in
> > /root/th/dpdk-stable-17.11.3/drivers/net/mlx5/mlx5.c:942:18: error:
> ?struct ibv_device_attr_ex? has no member named ?rss_caps?
> >     device_attr_ex.rss_caps.max_rwq_indirection_table_size;
> >                   ^
> >
> >
> > This is on Lentos 7.5 (3.10.0-862.14.4.el7.x86_64)
> >
> > With mlnx-en-4.4-1.0.1.0-rhel7.5-x86_64.iso installed
> >
> >
> > Any thoughts?
> >
> > thanks
> > ?
> > tony
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 12 Oct 2018 09:48:06 +0500
> From: Wajeeha Javed <wajeeha.javed123 at gmail.com>
> To: users at dpdk.org
> Subject: [dpdk-users] Increasing the NB_MBUFs of PktMbuf MemPool
> Message-ID:
>         <
> CAAQUUHUbowa5EnTiOhsaimAXNJXxjxKgPY1GAsqR+EUtoGL_2w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I am in the process of developing  DPDK based Application where I would
> like to delay the packets for about 2 secs. There are two ports connected
> to DPDK App and sending traffic of 64 bytes size packets at a line rate of
> 10GB/s. Within 2 secs, I will have 28 Million packets for each of the port
> in delay application. The maximum RX Descriptor size is 16384. I am unable
> to increase the number of Rx descriptors more than 16384 value. Is it
> possible to increase the number of Rx descriptors to a large value. e.g.
> 65536.  Therefore I copied the mbufs using the pktmbuf copy code(shown
> below) and free the packet received. Now the issue is that I can not copy
> more than 5 million packets because the  nb_mbufs of the mempool can't be
> more than 5 Million (#define NB_MBUF 5000000). If I increase the NB_MBUF
> macro from more than 5 Million, the error is returned unable to init mbuf
> pool. Is there a possible way to increase the mempool size?
>
> Furthermore, kindly guide me if this is the appropriate mailing list for
> asking this type of questions.
>
> <Code>
>
> static inline struct rte_mbuf *
>
> pktmbuf_copy(struct rte_mbuf *md, struct rte_mempool *mp)
> {
> struct rte_mbuf *mc = NULL;
> struct rte_mbuf **prev = &mc;
>
> do {
>     struct rte_mbuf *mi;
>
>     mi = rte_pktmbuf_alloc(mp);
>     if (unlikely(mi == NULL)) {
>         rte_pktmbuf_free(mc);
>
>         rte_exit(EXIT_FAILURE, "Unable to Allocate Memory. Memory
> Failure.\n");
>         return NULL;
>     }
>
>     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->next = NULL;
>     mi->pkt_len = md->pkt_len;
>     mi->nb_segs = md->nb_segs;
>     mi->ol_flags = md->ol_flags;
>     mi->packet_type = md->packet_type;
>
>    rte_memcpy(rte_pktmbuf_mtod(mi, char *), rte_pktmbuf_mtod(md, char *),
> md->data_len);
>    *prev = mi;
>    prev = &mi->next;
> } while ((md = md->next) != NULL);
>
> *prev = NULL;
> return mc;
>
> }
>
> </Code>
>
> *Reference:*  http://patchwork.dpdk.org/patch/6289/
>
> Thanks & Best Regards,
>
> Wajeeha Javed
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 12 Oct 2018 11:56:48 +0300
> From: Andrew Rybchenko <arybchenko at solarflare.com>
> To: Wajeeha Javed <wajeeha.javed123 at gmail.com>, <users at dpdk.org>
> Subject: Re: [dpdk-users] Increasing the NB_MBUFs of PktMbuf MemPool
> Message-ID: <b71716b2-2888-6828-3cfc-568c684c3181 at solarflare.com>
> Content-Type: text/plain; charset="utf-8"; format=flowed
>
> Hi,
>
> On 10/12/18 7:48 AM, Wajeeha Javed wrote:
> > Hi,
> >
> > I am in the process of developing  DPDK based Application where I would
> > like to delay the packets for about 2 secs. There are two ports connected
> > to DPDK App and sending traffic of 64 bytes size packets at a line rate
> of
> > 10GB/s. Within 2 secs, I will have 28 Million packets for each of the
> port
> > in delay application. The maximum RX Descriptor size is 16384. I am
> unable
> > to increase the number of Rx descriptors more than 16384 value. Is it
> > possible to increase the number of Rx descriptors to a large value. e.g.
> > 65536.  Therefore I copied the mbufs using the pktmbuf copy code(shown
> > below) and free the packet received. Now the issue is that I can not copy
> > more than 5 million packets because the  nb_mbufs of the mempool can't be
> > more than 5 Million (#define NB_MBUF 5000000). If I increase the NB_MBUF
> > macro from more than 5 Million, the error is returned unable to init mbuf
> > pool. Is there a possible way to increase the mempool size?
>
> I've failed to find explicit limitations from the first glance.
> NB_MBUF define is typically internal to examples/apps.
> The question I'd like to double-check if the host has enought
> RAM and hugepages allocated? 5 million mbufs already require about
> 10G.
>
> Andrew.
>
>
> End of users Digest, Vol 155, Issue 7
> *************************************
>


More information about the users mailing list