Date: Sat, 18 Mar 2017 09:52:31 +0100 From: Vincenzo Maffione <v.maffione@gmail.com> To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= <olivier@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? Message-ID: <CA%2B_eA9g73TQBzZ17K5ZjFYBR_zfL7rrsqoCEJNzn%2Bhd-0vGVzQ@mail.gmail.com> In-Reply-To: <CA%2Bq%2BTcobz8hhcUg%2BX5z5wuVpMmcF9coQhm4J3u7Sh8yWdkDe=g@mail.gmail.com> References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <CA%2B_eA9jYxRoi2HPcVjKbifTM43nnHeMQGDmmQvsw5UdXtLmFug@mail.gmail.com> <CA%2Bq%2BTcobz8hhcUg%2BX5z5wuVpMmcF9coQhm4J3u7Sh8yWdkDe=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Olivier, You're right, the checksum computation in hardware is in general more efficient than software computation, at least for the TCP and UDP checksum. But point here is that netmap provides an hardware-independent (and simple) API for accessing the NIC, and each NIC has its own way to manage the offloadings (checksumming, TSO, etc.). Some NICs (e.g. Intel), use additional context descriptors (ring slots) to store metadata necessary to compute the offloadings (e.g. where the checksum is in the packet, where to start checksumming, how many bytes, etc.). These context descriptors would break the linear correspondency between netmap slot (struct netmap_ring) and the NIC-specific ring, so that netmap should keep track of the "delta". Also, more metadata information would be needed in the netmap slot, which we don't want to become complex as the sk_buff and mbuf need. In the end, these complexities would make netmap datapath more similar in complexity to the the legacy "mbuf/network stack datapath", and additional complexity would have a performance hit (so more cycles per packet). Moreover, netmap is mostly designed for middleboxes, that do not need to compute TCP/UDP checksum. They may need to compute IP checksum, but that can be done quite efficiently also in software. pkt-gen is a test tool that has grown in complexity as we keep adding more features to netmap. We use it internally for testing, but it is not a fully featured packet generator, optimized for all the possible usages! >From your description, you are saying that pkt-gen computes the UDP checksum for each transmitted packet when you use the "range options". That's not very smart, pkt-gen could pre-compute all the different checksums in the range just once, so that you don't need to compute them again and again. So as I see it the real problem is pkt-gen with range options: it could be written in a smarted way. Point is that you normally want to use netmap for middleboxes, and in these cases you normally don't need to compute UDP/TCP checksum, like pkt-gen does. If you really want to design a fully-featured, optimized packet-generator with netmap (e.g. with traffic distributions, etc.), you can definitely do that, but you will for sure want to pre-build packets! Cheers, Vincenzo 2017-03-17 23:35 GMT+01:00 Olivier Cochard-Labb=C3=A9 <olivier@freebsd.org>= : > On Fri, Mar 17, 2017 at 6:51 PM, Vincenzo Maffione <v.maffione@gmail.com> > wrote: > >> >> When using your physical NICs with netmap, you need to disable the >> offloadings because netmap is not able to program the NIC to perform the= se >> offloadings. This is a design decision that has been taken to preserve >> simplicity and efficiency. >> > > =E2=80=8BHi, > > What do you mean by efficiency ? > For the netmap's pkt-gen tool, the option of using range for source or > destination IP address has some big impact because the software checksum > calculation. > Hopefully the Chelsio drivers allow to re-enable checksum offloading=E2= =80=8B in > netmap mode: This is mandatory for reaching 10G line-rate with pkt-gen > (with the range option). > > Regards, > > Olivier > > --=20 Vincenzo Maffione
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9g73TQBzZ17K5ZjFYBR_zfL7rrsqoCEJNzn%2Bhd-0vGVzQ>