Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756941Ab0FII3u (ORCPT ); Wed, 9 Jun 2010 04:29:50 -0400 Received: from mga02.intel.com ([134.134.136.20]:50423 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370Ab0FII3r convert rfc822-to-8bit (ORCPT ); Wed, 9 Jun 2010 04:29:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.53,390,1272870000"; d="scan'208";a="628804941" From: "Xin, Xiaohui" To: Stephen Hemminger CC: "netdev@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mst@redhat.com" , "mingo@elte.hu" , "davem@davemloft.net" , "herbert@gondor.apana.org.au" , "jdike@linux.intel.com" Date: Wed, 9 Jun 2010 16:29:28 +0800 Subject: RE: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. Thread-Topic: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. Thread-Index: AcsFzfD/N9cuOWprTE6i+FqKIrafowB2hQOw Message-ID: References: <1275732899-5423-1-git-send-email-xiaohui.xin@intel.com> <20100606161348.427822fb@nehalam> In-Reply-To: <20100606161348.427822fb@nehalam> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1936 Lines: 35 >-----Original Message----- >From: Stephen Hemminger [mailto:shemminger@vyatta.com] >Sent: Monday, June 07, 2010 7:14 AM >To: Xin, Xiaohui >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org; >mst@redhat.com; mingo@elte.hu; davem@davemloft.net; herbert@gondor.apana.org.au; >jdike@linux.intel.com >Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. > >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 ... > Yes, I agree on your concern at some extent. But the skbs which use external pages in our cases have short travels which start from NIC driver and then forward to the guest immediately. It will not travel into host kernel stack or any filters which may avoid many problems you have mentioned here. Another point is that we try to make the solution more generic to different NIC drivers, then many drivers may use the way without modifications. >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? The pool is not fixed size, it's the size of usable buffers submitted by guest virtio-net driver. Guest virtio-net will check how much buffers are filled and do resubmit. What a slow listener mean? A slow NIC driver? Thanks Xiaohui -- 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/