RE: Some performance measurements on the FreeBSD network stack

Yup, all good points. In fact we have considered all of these while doing
the work. In case you haven't seen it already, we did write about these 
issues in our paper and how we tried to address those, flow-table was one
of the solutions.

http://dl.acm.org/citation.cfm?id=1592641

--Qing


> >
> > Well, the routing table no longer maintains any lle info, so there
> > isn't much to copy out the rtentry at the completion of route
> > lookup.
> >
> > If I understood you correctly, you do believe there is a lot of value
> > in Flowtable caching concept, but you are not suggesting we reverting
> > back to having the routing table maintain L2 entries, are you ?
> 
> I see a lot of value in caching in general.
> 
> Especially for a bound socket it seems pointless to lookup the
> route, iface and mac address(es) on every single packet instead of
> caching them. And, routes and MAC addresses are volatile anyways
> so making sure that we do the lookup 1us closer to the actual use
> gives no additional guarantee.
> 
> The frequency with which these info (routes and MAC addresses)
> change clearly influences the mechanism to validate the cache.
> I suppose we have the following options:
> 
> - direct notification: a failure in a direct chain of calls
>   can be used to invalidate the info cached in the socket.
>   Similarly, some incoming traffic (e.g. TCP RST, FIN,
>   ICMP messages) that reach a socket can invalidate the cached values
> - assume a minimum lifetime for the info (i think this is what
>   happens in the flowtable) and flush it unconditionally
>   every such interval (say 10ms).
> - if some info changes infrequently (e.g. MAC addresses) one could
>   put a version number in the cached value and use it to validate
>   the cache.
> 
> cheers
> luigi