Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2018 09:21:26 +0100
From:      Vincenzo Maffione <v.maffione@gmail.com>
To:        Joe Buehler <aspam@cox.net>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: netmap ixgbevf mtu
Message-ID:  <CA%2B_eA9gm=MymUBOMm%2Bo3KWxEHOBLzutx09i8bsHsjLKiyQw4OA@mail.gmail.com>
In-Reply-To: <5AB01439.3090003@cox.net>
References:  <5AAC49BE.3030508@cox.net> <5AAC4A96.1040107@cox.net> <5AB01439.3090003@cox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
2018-03-19 20:49 GMT+01:00 Joe Buehler <aspam@cox.net>:

> Vincenzo Maffione wrote:
>
> > To receive a frame larger than the RX buffer size you need multiple
> > netmap slots (as multiple descriptors are
> > used by the hardware), looking at the NS_MOREFRAG flag.
> > See the example code in utils/functional.c::rx_one().
>
> This works fine -- thanks.
>
> > Also TX may have per-slot limitations (e.g. due to the size of the NIC
> > TX fifo), but this is usually > 9K, so using a single descriptor per
> > packet should always
> > be ok. However, you can also use multiple slots on the TX side (see
> > utils/functional.c::tx_one()).
>
> Trying to split TX frames into multiple buffers does not work, the NIC is
> sending 2048 byte frames (the buf_size I am using).
>
> I will re-check my code.  Do I need a particular version of ixgbevf
> perhaps?
>
>
I don't think so, but you need to use the latest netmap from github.
The NS_MOREFRAG support for ixgbe/ixgbevf is here
https://github.com/luigirizzo/netmap/blob/master/LINUX/ixgbe_netmap_linux.h#L344-L345

The problem is that nobody really tried to use NS_MOREFRAG on ixgbevf
transmission so far.
So there may be a bug on how we set the flags in the hardware descriptor.
We should look at what the driver does. Here
https://elixir.bootlin.com/linux/v3.8/source/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c#L2903
I see that the olinfo_status field is set with the total frame length (and
not just the fragment length).
In the netmap code we set to the fragment length, so that's probably why
you see that behaviour.
Here
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf
in sec. 7.2.3.2.4 I read that we need to properly set the olinfo_status
field on the firsts TX descriptor, while the others are irrelevant.

Cheers,
  Vincenzo





> Joe Buehler
>



-- 
Vincenzo Maffione



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9gm=MymUBOMm%2Bo3KWxEHOBLzutx09i8bsHsjLKiyQw4OA>