Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752920Ab0FHF16 (ORCPT ); Tue, 8 Jun 2010 01:27:58 -0400 Received: from ringil.hengli.com.au ([216.59.3.182]:41090 "EHLO arnor.apana.org.au" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751918Ab0FHF14 (ORCPT ); Tue, 8 Jun 2010 01:27:56 -0400 Date: Tue, 8 Jun 2010 15:27:44 +1000 From: Herbert Xu To: Stephen Hemminger Cc: xiaohui.xin@intel.com, netdev@vger.kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, mst@redhat.com, mingo@elte.hu, davem@davemloft.net, jdike@linux.intel.com Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. Message-ID: <20100608052744.GA21547@gondor.apana.org.au> References: <1275732899-5423-1-git-send-email-xiaohui.xin@intel.com> <20100606161348.427822fb@nehalam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100606161348.427822fb@nehalam> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1959 Lines: 46 On Sun, Jun 06, 2010 at 04:13:48PM -0700, Stephen Hemminger wrote: > Still not sure this is a good idea for a couple of reasons: > > 1. We already have lots of special cases with skb's (frags and fraglist), > and skb's travel through a lot of different parts of the kernel. So any > new change like this creates lots of exposed points for new bugs. Look > at cases like MD5 TCP and netfilter, and forwarding these SKB's to ipsec > and ppp and ... > > 2. SKB's can have infinite lifetime in the kernel. If these buffers come from > a fixed size pool in an external device, they can easily all get tied up > if you have a slow listener. What happens then? I agree with Stephen on this. FWIW I don't think we even need the external pages concept in order to implement zero-copy receive (which I gather is the intent here). Here is one way to do it, simply construct a completely non-linear packet in the driver, as you would if you were using the GRO frags interface (grep for napi_gro_frags under drivers/net for examples). This way you can transfer the entire contents of the packet without copying through to the other side, provided that the host stack does not modify the packet. If the host side did modify the packet then we have to incur the memory cost anyway. IOW I think the only feature provided by the external pages construct is allowing the skb->head area to be shared without copying. I'm claiming that this can be done by simply making skb->head empty. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/