From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 16:47:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 010854A6; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DA6EEAE; Sat, 20 Sep 2014 16:47:40 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id f12so3852968qad.5 for ; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FyPxHPmyL73FQT9YYshE4Cwu/ClZkJ674XYdXUrplnU=; b=pYLm4Sn8/zoPPx80iAmfzWdGgiwTJ33s8ogVsWDnEEgWcEad6eg8LvMQkUfjtWDpEU Pd65cEFNAB3zO4ka5LFnfpsIFO9iFcjebS8SboUfA34H47kcfwyzhX33eUR9z3BvnvLP jOimq96BEvbv5lpcaxDqZG813aIeqxVf22zwHCPVHPxl9EJhj01d1tEeX/8uBJ+E4AIY k9BtiFp+AKpELMG90xu1X42uKFzv0SlRNAwN6AY+IeGgsqpCHRKdFq1AGS0KD5MU8c2P yeZpNU/u6R0Ue87luMBcXal3xomlMEvRoFfxINrod3cmkwqtzH0y1S3AIcB8+xSKfWI1 wKVw== MIME-Version: 1.0 X-Received: by 10.140.95.234 with SMTP id i97mr9983143qge.93.1411231659586; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) Received: by 10.140.104.241 with HTTP; Sat, 20 Sep 2014 09:47:39 -0700 (PDT) In-Reply-To: References: <5419EE95.40600@selasky.org> Date: Sat, 20 Sep 2014 18:47:39 +0200 Message-ID: Subject: Re: [RFC] Patch to add Software/Generic Segmentation Offload (GSO) support in FreeBSD From: Stefano Garzarella To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , Adrian Chadd , "freebsd-net@freebsd.org" , George Neville-Neil , freebsd-current , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:47:41 -0000 Hi Freddie, this is a preliminary version and, for now, we have not analyzed all aspects. Thanks for your suggestion. We will try to analyze how the GSO affects IPFW as soon as possible. Cheers, Stefano 2014-09-18 17:27 GMT+02:00 Freddie Cash : > On Thu, Sep 18, 2014 at 7:16 AM, Stefano Garzarella < > stefanogarzarella@gmail.com> wrote: > >> I saw the discussion about TSO, but the GSO is a software >> implementation unrelated with the hardware. >> Furthermore, if the TSO is enabled (and supported by the NIC), the GSO i= s >> not executed, because is useless. >> >> After the execution of the GSO, the packets, that are passed to the devi= ce >> driver, are smaller (or equal) than MTU, so the TSO is unnecessary. For >> this reason the GSO doesn't look neither "ifp->if_hw_tsomax" nor hardwar= e >> segment limits. >> >> The GSO is very useful when you can't use the TSO. >> > > =E2=80=8BHow does GSO affect IPFW, specifically the libalias(3)-based, in= -kernel > NAT? The ipfw(8) man page mentions that it doesn't play nicely with > hardware-based TSO, and that one should disable TSO when using IPFW NAT. > > Will the software-based GSO play nicely with IPFW NAT?=E2=80=8B Will it = make any > difference to packet throughput through IPFW? > > Or is it still way too early in development to be worrying about such > things? :) > > -- > Freddie Cash > fjwcash@gmail.com > --=20 *Stefano Garzarella* stefano.garzarella@gmail.com