>-----Original Message----- >From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On Behalf Of Andi >Kleen >Sent: Monday, June 07, 2010 3:51 PM >To: Stephen Hemminger >Cc: Xin, Xiaohui; netdev@xxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; >linux-kernel@xxxxxxxxxxxxxxx; mst@xxxxxxxxxx; mingo@xxxxxxx; davem@xxxxxxxxxxxxx; >herbert@xxxxxxxxxxxxxxxxxxx; jdike@xxxxxxxxxxxxxxx >Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. > >Stephen Hemminger <shemminger@xxxxxxxxxx> writes: > >> 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? > >3. If they come from an internal pool what happens when the kernel runs >low on memory? How is that pool balanced against other kernel >memory users? > The size of the pool is limited by the virtqueue capacity now. If the virtqueue is really huge, then how to balance on memory is a problem. I did not consider it clearly how to tune it dynamically currently... >-Andi > >-- >ak@xxxxxxxxxxxxxxx -- Speaking for myself only. >-- >To unsubscribe from this list: send the line "unsubscribe kvm" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
