On Fri, Jul 29, 2005 at 11:46:13AM -0700, Max Krasnyansky ([EMAIL PROTECTED])
wrote:
> 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 :).
Exactly because of this :)
zap_pte_range() is what is needed for update_address(), but it is not
exported.
TLB flushing is also can be optimized for platforms, which support
more optimized selective tlb removing.
But it is not exported too :)
> 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.
unlikely() is definitely a failed prediction in this case.
> Max
--
Evgeniy Polyakov
-
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
