From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Subject: Re: MAX_SKB_FRAGS and GRO Date: Mon, 08 Feb 2010 09:53:51 -0800 Message-ID: <4B704FAF.4010209@hp.com> References: <20100208100306.GQ32246@kryten> <20100208124704.GA8538@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Herbert Xu , Anton Blanchard , "Kirsher, Jeffrey T" , "Allan, Bruce W" , "Duyck, Alexander H" , "Waskiewicz Jr, Peter P" , "Ronciak, John" , "divy@chelsio.com" , "netdev@vger.kernel.org" To: "Brandeburg, Jesse" Return-path: Received: from g1t0028.austin.hp.com ([15.216.28.35]:18348 "EHLO g1t0028.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752205Ab0BHRxu (ORCPT ); Mon, 8 Feb 2010 12:53:50 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: >>First of all this isn't GRO, but RSC. With GRO we impose extra >>restrictions on what packets can be merged while RSC is more >>permissive. > > > Herbert is right. Just for clarity lets not call it "hardware GRO" but > instead just call it RSC or hardware RSC (receive side coalescing) I'll paint a stripe on the bikeshed and suggest something even more explicit - if it is the hardware, how about HRC (Hardware Receive Coalescing) or NRC (Nic Receive Coalescing). rick jones