Re: [PATCH][RFC 23/23]: Support for zero-copy TCP transmit of user space data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Evgeniy Polyakov, on 12/24/2008 09:08 PM wrote:
On Wed, Dec 24, 2008 at 08:46:56PM +0300, Vladislav Bolkhovitin (vst@xxxxxxxx) wrote:
I think in most cases there would be possibility to embed sk_transaction_token to some higher level structure. E.g. Xen apparently should have something to track packets passed through host/guest boundary. From other side, kmem cache is too well polished to have much overhead. I doubt, you would even notice it in this application. In most cases allocation of such small object in it using SLUB is just about the same as a list_del() under disabled IRQs.

I definitely would not rely on that, especially at cache reclaim time.
But it of course depends on the workload and maybe appropriate for the
cases in question. The best solution I think is to combine tag and
separate destructur, so that those who do not want to allocate a token
could still get notification via destructor callback.

Although I agree that any additional allocation is something, which should be avoided, *if possible*. But you shouldn't overestimate the overhead of the sk_transaction_token allocation in cases, when it would be needed. At first, sk_transaction_token is quite small, so a single page in the kmem cache would keep about 100 of them, hence the slow allocation path would be called only once per 100 objects. Second, in many cases ->sendpages() needs to allocate a new skb, so already there is at least one such allocations on the fast path.

Actually, it doesn't look like the skb shared info destructor alone can't solve the task we are solving, because we need to know not when an skb transmittion finished, but when transmittion of our *set of pages* finished. Hence, with skb shared info destructor we would need also to invent some way to track set of pages <-> set of skbs translation (you refer it as combining tag and separate destructor), which would bring this solution on the entire new complexity level for no gain over the sk_transaction_token solution.

Thanks,
Vlad



--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux