Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Jun 2016 18:47:52 -0400
From:      Ryan Stone <rysto32@gmail.com>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        Andrew Vylegzhanin <avv314@gmail.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: Is netmap jumbo frames broken in STABLE?
Message-ID:  <CAFMmRNy=PEFOxM4tGM7TQqpMnhTba17ACiaOcfuG8fkDET0RZw@mail.gmail.com>
In-Reply-To: <CA%2BhQ2%2BjcT_E4osrTB00%2Bf0gwSCoG_Zy%2BVdU8LXndqsjnmxPQ3Q@mail.gmail.com>
References:  <CA%2BBi_YhqCnt5pQ_hC5zWdBp24=Zn3Rcj29AwtMrguPhSoJZSdQ@mail.gmail.com> <CA%2BhQ2%2BjcT_E4osrTB00%2Bf0gwSCoG_Zy%2BVdU8LXndqsjnmxPQ3Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
The use of mbuf clusters larger than a single page really doesn't work.
The problem is that over time physical memory becomes fragmented and
eventually 9K of contiguous memory can't be allocated anymore.  This is why
many drivers now limit themselves to page-sized clusters.

On Mon, Jun 6, 2016 at 10:03 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:

> On Mon, Jun 6, 2016 at 3:22 PM, Andrew Vylegzhanin <avv314@gmail.com>
> wrote:
>
> > Hello all,
> >
> >
> > I have an application that uses netmap for capture jumbo frames. The
> frames
> > are fixed size and have fixed rate (for example size 5166, rate 50000
> pps).
> > The frames are pure Ethernet, without IP header.
> >
> >
> > Everything works fine in 10.0-RELEASE, 10.1-RELEASE.
> >
> >
> > Starting from 10.3 and actual 10-STABLE I've got wrong data from netmap
> > ring. It's looks like packet data broke and packet split on two parts
> 4092
> > and 1070 bytes,  where original size was 5166.
> >
> > A code ring precessing is based on macros from netmap_user.h :
> >
> >
> >         n =3D nm_ring_space(ring);
> >
> >         for (rx =3D 0; rx < limit; rx++) {
> >
> >                 struct netmap_slot *slot =3D &ring->slot[cur];
> >
> >                 char *p =3D NETMAP_BUF(ring, slot->buf_idx);
> >
> >                 process_payload(p, slot->len, datapx);
> >
> >                 cur =3D nm_ring_next(ring, cur);
> >
> >         }
> >
> >         ring->head =3D ring->cur =3D cur;
> >
> >
> > Here is netmap sysctl's:
> >
> > dev.netmap.buf_num=3D81920
> >
> > dev.netmap.ring_size=3D73728
> >
> > dev.netmap.buf_size=3D5248
> >
> >
> > Hardware is Dell R720 (2x E5-2643 v2) with four Intel Ethernet 10G 2P
> X520
> > Adapter. I use only one hardware queue per interface.
> >
> >
> > BTW, may be a new version of Intel ixgbe driver (3.1.13-k) is a reason?
> >
> >
> =E2=80=8BHi,
> yes I suspect the problem may be in the new ixgbe driver,
> probably it programs the hardware to limit buffer sizes to 4k
> even when large MTUs are in use,
> so the receiver will split
> the incoming frame in two buffers, while netmap is expecting
> only one.
> I suggest to have a look at the ioctl handler (in the driver)
> that handles the MTU setting and compare with the code
> in the previous driver.
>
> cheers
> luigi
>
>
> > Does it make sense to try with 11-CURRENT?
> >
> >
> > Thank you in advance.
> >
> >
> > --
> >
> > Andrew
> > _______________________________________________
> > freebsd-net@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
> >
>
>
>
> --
> -----------------------------------------+-------------------------------
>  Prof. Luigi RIZZO, rizzo@iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/        . Universita` di Pisa
>  TEL      +39-050-2217533               . via Diotisalvi 2
>  Mobile   +39-338-6809875               . 56122 PISA (Italy)
> -----------------------------------------+-------------------------------
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNy=PEFOxM4tGM7TQqpMnhTba17ACiaOcfuG8fkDET0RZw>