From owner-freebsd-net@FreeBSD.ORG Wed Apr 2 03:26:56 2014 Return-Path: Delivered-To: freebsd-net@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 7C921A9C for ; Wed, 2 Apr 2014 03:26:56 +0000 (UTC) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 505C8EE8 for ; Wed, 2 Apr 2014 03:26:56 +0000 (UTC) Received: by mail-pb0-f48.google.com with SMTP id md12so10796186pbc.21 for ; Tue, 01 Apr 2014 20:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uNOtmipsvrn2iqVmPNSGfn7mBKDQNnKL4AOXb/jxOx0=; b=T4Ulyr1TTQLQu2brymTpOUow5mBIfHYqOMnM7xQ4raXxt83YHwIUd0qU9QGzuoI35x GtkMWXQ8nG+0ZJiHCK3cIvdD4xLbqtafQt9AFspIAQY1HSmtTvS7TUFVT4gDEb3sRRTS dpN8XfZ08yCrgnfhaEAlV131z9GNjYxifEzJ6ukG7wUwKIzc8L9pEVtYmGuFembDBBwm mWThJKJ8a6mcpguEDWEhkIwq5XQnzA4b10ncq5UQTCsuTNBgTfGKpOfx2gdhu5cszj29 kC04Wd1oZY0BHDKbzwlGB9+p1wyMmYKJ/DIVmLHP4aEelXGCvsJkWLlSc06u56oRepqg Ry4w== X-Received: by 10.68.170.66 with SMTP id ak2mr35035012pbc.5.1396409215428; Tue, 01 Apr 2014 20:26:55 -0700 (PDT) Received: from kmatoMacBook-Pro.local ([27.24.140.121]) by mx.google.com with ESMTPSA id op3sm1024873pbc.40.2014.04.01.20.26.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 20:26:54 -0700 (PDT) Message-ID: <533B8377.9060209@gmail.com> Date: Wed, 02 Apr 2014 11:26:47 +0800 From: k simon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rick Macklem , "freebsd-net@freebsd.org >> FreeBSD Net" Subject: Re: 9.2 ixgbe tx queue hang References: <1292881633.1858906.1395960241007.JavaMail.root@uoguelph.ca> In-Reply-To: <1292881633.1858906.1395960241007.JavaMail.root@uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 02 Apr 2014 03:26:56 -0000 Hi, Rick, Does these patches will commit to the stable soon, or I had to patch it manually? Regards Simon 于 14-3-28 6:44, Rick Macklem 写道: > Christopher Forgeron wrote: >> >> >> >> >> >> >> On Wed, Mar 26, 2014 at 9:35 PM, Rick Macklem < rmacklem@uoguelph.ca >>> wrote: >> >> >> >> >> I've suggested in the other thread what you suggested in a recent >> post...ie. to change the default, at least until the propagation >> of driver set values is resolved. >> >> rick >> >> >> >> I wonder if we need to worry about propagating values up from the >> sub-if's - Setting the default in if.c means this is set for all >> if's, and it's a simple 1 line code change. If a specific 'if' needs >> a different value, it can be set before ether_attach() is called. >> >> >> I'm more concerned with the equation we use to calculate if_hw_tsomax >> - Are we considering the right variables? Are we thinking on the >> wrong OSI layer for headers? >> > Well, I'm pragmatic (which means I mostly care about some fix that works), > but it seems to me that: > - The problem is that some TSO enabled network drivers/hardware can only > handle 32 transmit segments (or 32 mbufs in the chain for the TSO packet > to be transmitted, if that is clearer). > --> Since the problem is in certain drivers, it seems that those drivers > should be where the long term fix goes. > --> Since some hardware can't handle more than 32, it seems that the > driver should be able to specify that limit, which tcp_output() can > then apply. > > I have an untested patch that does this by adding if_hw_tsomaxseg. > (The attachment called tsomaxseg.patch.) > > Changing if_hw_tsomax or its default value is just a hack that gets tcp_output() > to apply a limit that the driver can then fix to 32 mbufs in the chain via > m_defrag(). > > Since if_hw_tsomax (and if_hw_tsomaxseg in the untested patch) aren't > propagated up through lagg, that needs to be fixed. > (Yet another attached untested patch called lagg.patch.) > > As I said before, I don't see these patches getting tested/reviewed etc > in time for 9.3, so I think reducing the default value of if_hw_tsomax > is a reasonable short term hack to work around the problem. > (And it sounds like Pyun YongHyeon has volunteered to fix many of the > drivers, where the 32 limit isn't a hardware one.) > > rick > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >