On Wed, 14 Apr 2004, Henrik Nordstrom wrote: > On Wed, 14 Apr 2004, Nagendra Singh Tomar wrote: > > > > This should not be difficult if using non-linear sk_buff. > > > > You are right, but when I was writing this mail I had non-SG devices in > > mind. Even for a regular ethernet frame of 1500 bytes we can gain a lot > > if can put the data portion in noncacheable region. > > If you want different cache status for header and rest of data you need to > split the allocations to different zones. To be able to have the > allocation split the sk_buff must be non-linear. This from the requirement > of different cache levels and is independent of the type of driver/device > used. That is one way of doing it, but it breaks for non-SG devices. They will not be able to DMA the header and data at different places. Even for these kind of devices we can have skb->data point to the last 128 bytes of a page, of which the next consecutive page is also free (we can have a pool of such objects) +-----+ | | | P1 | | |<----- (skb->data) | | +-----+ | | | P2 | | | | | +-----+ This way we can set the P1 (page containing the header) as cacheable and P2 as noncacheable. I know it looks ugly but we can make use of the remaining of P1 for some slab. > > Yes, this means each and every driver needs to be modified to use the > feature, but so is often the case when adding new features. Only those drivers which are sure that the received payload will not be touched, e.g devices that do Rx checksum verification. > > > > I am doubtful, but I am possibly biased from working a lot with iptables > > > and often accessing the payload while the packet is forwarded for NAT > > > etc.. but maybe. > > > > If the data payload has to be touched in anyway then putting it in > > noncacheable area will turn to be a killer. > > Which is why I say I am possibly biased.. not everyone needs to access the > data payload beyond the headers. > > Regards > Henrik > Thanx for your comments. tomar -- -- You have moved the mouse. Windows must be restarted for the changes to take effect. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
