From owner-freebsd-current@FreeBSD.ORG Mon Sep 8 23:33:12 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 CA14623A; Mon, 8 Sep 2014 23:33:12 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 9347A6D5; Mon, 8 Sep 2014 23:33:12 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id lj1so4892951pab.27 for ; Mon, 08 Sep 2014 16:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GyaN/nDGqIp/YKJOHkCqeBf4ynQViDu25B9P/rD03v8=; b=GMnkyKufNt3tTvsYj5bILeiv0kKft7URJqI6VsODXwCX0pQrk/Ib3lw2CU5GXwsh6u 4cToEQKSPRV3pZ845Fi3TJTu+9H0/o5iGK/pvZC9dZVyHCnkH/tQUBvZre0gPesXfR99 ZVNS30HTsDqSHYcOwMgni+9y61dAcokPuiwNjbgqBxIvDk86RE747bvn3/RIkwkr7JUb q3aJwRpwzHZzsJWoxSWP41x4KUvgQpB1RshOV19yEbojgq5FLb+67J87Wgb6/XguqSAl M+hF3uwg9ueQ+Jz/hpJGknrvOy0B7P7HfCIL5Yu3vvEqPI3duxafa6XJGTfwaGet6SnG IKFA== X-Received: by 10.70.47.42 with SMTP id a10mr12368287pdn.14.1410219192067; Mon, 08 Sep 2014 16:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.55.162 with HTTP; Mon, 8 Sep 2014 16:32:31 -0700 (PDT) In-Reply-To: <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> References: <540D444C.6090904@selasky.org> <1882852102.33387181.1410177939640.JavaMail.root@uoguelph.ca> From: Eric Joyner Date: Mon, 8 Sep 2014 16:32:31 -0700 Message-ID: Subject: Re: [RFC] Patch to improve TSO limitation formula in general To: Rick Macklem Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Hans Petter Selasky , "freebsd-net@freebsd.org" , FreeBSD Current , Scott Long , Jack F Vogel 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: Mon, 08 Sep 2014 23:33:13 -0000 Let me remove my concerns earlier in the thread -- this patch won't negatively affect any of our drivers; and the problem I mentioned with ixl would require a change somewhere further up the stack. --- - Eric Joyner On Mon, Sep 8, 2014 at 5:05 AM, Rick Macklem wrote: > Hans Petter Selasky wrote: > > On 09/06/14 00:09, Rick Macklem wrote: > > > Hans Petter Selesky wrote: > > >> On 09/05/14 23:19, Eric Joyner wrote: > > >>> There are some concerns if we use this with devices that ixl > > >>> supports: > > >>> > > >>> - The maximum fragment size is 16KB-1, which isn't a power of 2. > > >>> > > >> > > >> Hi Eric, > > >> > > >> Multiplying by powers of two are more fast, than non-powers of > > >> two. > > >> So > > >> in this case you would have to use 8KB as a maximum. > > >> > > > Well, I'm no architecture expert, but I really doubt the CPU delay > > > of a > > > non-power of 2 multiply/divide is significant related to doing > > > smaller > > > TSO segments. Long ago (as in 1970s) I did work on machines where > > > shifts > > > for power of 2 multiply/divide was preferable, but these days I > > > doubt it > > > is going to matter?? > > > > > >>> - You can't get the maximum TSO size for ixl devices by > > >>> multiplying > > >>> the > > >>> maximum number of fragments by the maximum size. > > >>> Instead the number of fragments is AFAIK unlimited, but a segment > > >>> can only > > >>> span 8 mbufs (including the [up to 3] mbufs containing the > > >>> header), > > >>> and the > > >>> maximum TSO size is 256KB. > > > > Hi, > > > > Maybe that can be a separate parameter? > > > > I see that your patch assumes that a segment can be any-length. That > > is > > not always the case. Remember there are JUMBO mbufs too. > > > I thought JUMBO mbufs were only going to be used on the receive side, > however I suppose if a packet is received into a JUMBO mbuf and then > forwarded on another interface... > > > With my patch, the maximum segment size is a separate parameter. The > > total number of TSO bytes is then not so useful. > > > Well, if you are referring to if_hw_tsomax, I'm not sure it was the > best plan to begin with. It was implemented for xen and I'm not sure > that any other driver uses it as of now. > > However... > I'm not a network/hardware guy, but it seems some devices do have > the IP_MAXPACKET limit (use the ip_len field in the ip header to > know how large the TSO segment is). There is also at least one device > (82598 chip for "ix" driver) that can handle more that IP_MAXPACKET, > so it seems appropriate to have a value that the driver can set. > > Since the maximum size of the gather list for transmit does seem to > vary a lot between devices, with several handling less than 35, it > does seem appropriate to allow drivers to specify that. > > If devices can't handle a single gather entry over a certain size, > I think that does need to be specified along with the max size of > the gather list, since the driver will need to use multiple gather > entries for a single mbuf and tcp_output() should take that into > account. > > In summary, yep, I basically agree. > > rick > ps: Who will look at your patch soon. > > > --HPS > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > > >