Evgeniy Polyakov wrote:
I'm almost convinced that remap can brake even with ring buffer at 1500
sizes. However we're talking about total per packet overhead here. At some
point you have to _unmap_ the thing once user-space app is done with it.
With ring buffer it's "memcpy()/kfree_skb()" where with mmap it's
"remap()/unmap()/kfree_skb()".
Unmapping is repeatedly being done in this driver - update_address() and
tlb_flush() does the thing.
Current code does skb freeing when it's slot needs to be used for the
next skb.
So this numbers already include mapping/unmapping.
Oh, I didn't realize that update_address() supposed to unmap the pages.
Ok. I'll think (started thinking already :)) about combining ring buffer (small
packets) and mmaping (large packets) in TUN/TAP driver.
btw Why didn't you use zap_page_range() for unmapping. It seems that it will do
the right thing if you keep PageReserved flag ? You can always add EXPORT_SYMBOL
even if it's not exported for modules :).
zap_page_range() marks PageReserved case as unlikely() so there will be branch
miss
prediction penalty, so I guess we will need something like
zap_reserved_page_range()
that assumes that pages are reserved.
Max
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
