From owner-freebsd-net@FreeBSD.ORG Wed Aug 20 09:32:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E69F88B5; Wed, 20 Aug 2014 09:32:28 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 305B8344F; Wed, 20 Aug 2014 09:32:28 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id v6so6483974lbi.38 for ; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5eT3lTm3TgjugthKLkDN25vxrfbSC4ZBgOuL9WpTP8o=; b=bWwUfIg3cCXlDeaTNK17k2iiIufLXDD2O5jzcZaBvEOWukrRbP6Ay2mnTWqHCpgcRh fe2RcLjjsXFSEPRcL1BVQ4aCdeKLr5fHhjYvuDxlnzQlsmiU6gNtLWyDhCoSQyLf9/qr I4vcvlahaTuVRPFHg2RqjQOIkh6MdFsSAD4VkO7/plUhmH+hTyhm83YjVu6+gcPfL6tu QtOI+6W+EL16fXYNN/Ss69XfJ21rJZUbT4oR2NkhuHVmpO/C4YRaJlg13hpi5PK61Tqd w98pXNfD7z0GkVLSiiww3w2UwQosKZxSsVlkB2tjr+juJzIiq/nQVewQ2AkfIFKpRdq2 Kiew== MIME-Version: 1.0 X-Received: by 10.112.35.44 with SMTP id e12mr38763111lbj.13.1408527146067; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.244.2 with HTTP; Wed, 20 Aug 2014 02:32:26 -0700 (PDT) In-Reply-To: <53F44F91.2060006@selasky.org> References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> <53BD5385.4090208@selasky.org> <20140709163146.GA21731@ox> <53F44F91.2060006@selasky.org> Date: Wed, 20 Aug 2014 11:32:26 +0200 X-Google-Sender-Auth: KXSBRY2Umn7HUstkEjYX2X6Xqnk Message-ID: Subject: Re: [RFC] Add support for hardware transmit rate limiting queues [WAS: Add support for changing the flow ID of TCP connections] From: Luigi Rizzo To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 09:32:29 -0000 On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky wrote: > Hi, > > A month has passed since the last e-mail on this topic, and in the > meanwhile some new patches have been created and tested: > > Basically the approach has been changed a little bit: > > - The creation of hardware transmit rings has been made independent of th= e > TCP stack. This allows firewall applications to forward traffic into > hardware transmit rings aswell, and not only native TCP applications. Thi= s > should be one more reason to get the feature into the kernel. > > - A hardware transmit ring basically can have two modes: FIXED-RATE or > AUTOMATIC-RATE. In the fixed rate mode all traffic is sent at a fixed byt= es > per second rate. In the automatic mode you can configure a time after whi= ch > the TX queue must be empty. The hardware driver uses this to configure th= e > actual rate. In automatic mode you can also set an upper and lower transm= it > rate limit. > > - The MBUF has got a new field in the packet header: "txringid" > > - IOCTLs for TCP v4 and v6 sockets has been updated to allow setting of > the "txringid" field in the mbuf. > > The current patch [see attachment] should be much simpler and less > intrusive than the previous one. > =E2=80=8Bthe patch seems to include only part of the generic code (ie no io= ctls for manipulating the rates, no backend code). Do i miss something ? I have a few comments/concerns: + looks like flowid and txringid are overlapped in scope, both will be used (in the backend) to select a specific tx queue. I don't have a solution but would like to know how do you plan to address this -- does one have priority over the other, etc. + related to the above, a (possibly unavoidable) side effect of this type of changes is that mbufs explode with custom fields, so if we could perhaps make one between flowid and txringid, that would be useful. + is there a way to =E2=80=8Bavoid the replicated code for SIOCSTXRINGID (the ioctl handler, i suppose). Maybe make one function and call it from both ipv4 and ipv6, assuming there aren't other places like this. + i am not particularly happy about the explosion of ioctls for setting and getting rates. Next we'll want to add scheduling, and intervals, and queue sizes and so on. For these commands outside the critical path it would be preferable a single command with an extensible structure. Bikeshed material i am sure. cheers luigi