From owner-freebsd-net@freebsd.org Sat Mar 18 08:52:33 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38D84D11038 for ; Sat, 18 Mar 2017 08:52:33 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBC55145; Sat, 18 Mar 2017 08:52:32 +0000 (UTC) (envelope-from v.maffione@gmail.com) Received: by mail-ot0-x229.google.com with SMTP id a12so39355388ota.0; Sat, 18 Mar 2017 01:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BNoE2vqtPLWKffqLTlFcjGjE+xaTRHYPjKl+yq6n3nc=; b=rUHpCVfG3gtU3GuVHOg/4OYR1k+BJzjILFAYDy1K5jqie1Blv4C3mUclC1VswYX6qR tim98hEJPTYd9d/1vKyNsdkbs/N/ALwi8E2sVuBUEwm4uEC2kVJnJyZFnJr1Rouif+0k mjWiOx73oEN+S5ZJde4u/Q1ubGmdcOa33F4i5O2VIE5RdINcFTIf1FyQlDfPUB87cGU/ rLHVY6P9nXC/0mRu4fFbpaFCXfTMSH5ETSPqDQPYjKD+H8+HVilomWeeBMZ4OrhCXUoT Z5zQ9iiNQ5HS847qQogCkZQ2l+fdcM6q7bFZOWanrCpMPagR8AtbV440rOZpweUhCqc5 nC8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BNoE2vqtPLWKffqLTlFcjGjE+xaTRHYPjKl+yq6n3nc=; b=AamRkLnO6ilDb79qTNRqWAd3N1xRO70ivkiHTli5vvUP1/lS9PqxPHvTyrW1hzNx2Q HIWbCNMI2ajSGpbD7RlZW3KxlJ45ioxMAB+SGUaEDN9pRLW35+oo1IouhECThYL8GzsW mCyudEZOQlsvwy/6G8TCV7MMBi4YxaQTpRaJwgE8NIYXejsuVaY/+0+5Z26fUbEkYCmC ZQKTUvNcZLW8f5iA8psqaE/UKwnd4HHKcIO8bpnYVBK46CsRsCvm8oAc1f8CC5zypWsL grzE1BhRa3m7ADHLEmK2XnXeNxVCTdJFqNDLcMOmcC03DyyWZ6IpKrLH5yOHJxZkh4o0 hkDw== X-Gm-Message-State: AFeK/H0RQ8m6ijXG4K3N/amn7sO+g4QttnZkrM/wdLh7rLO8k+NqXAUt8nA7FN7H0w0e1gILAm2cX4LuTgCTWw== X-Received: by 10.157.73.138 with SMTP id g10mr9107496otf.56.1489827152105; Sat, 18 Mar 2017 01:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.50.45 with HTTP; Sat, 18 Mar 2017 01:52:31 -0700 (PDT) In-Reply-To: References: <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> From: Vincenzo Maffione Date: Sat, 18 Mar 2017 09:52:31 +0100 Message-ID: Subject: Re: Are ./valte-ctl and ./bridge friends or competitors? To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 08:52:33 -0000 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 = : > On Fri, Mar 17, 2017 at 6:51 PM, Vincenzo Maffione > 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