Extension of dummynet/ipfw to support userspace packet classification

[Luigi Rizzo]

On Wed, Oct 07, 2009 at 12:46:24PM -0700, Joe R wrote:
> We at ironport have a requirement to do bandwidth management, but the
> traffic classification (and selection of bandwidth pipes) is done in
> userspace. The reason classification is done in userspace is because the
> traffic classifications are something like streaming audio traffic, video
> traffic, based on website categories etc.
> 
> 
> 
> Our appliance is based on FreeBSD, and so we decided to look at dummynet to
> support our requirement. We could not use dummynet as such because it uses
> ipfw for packet classification, where packet classification (and pipe
> selection) is done in kernel based on tcp/ip parameters like IP and port.
> 
> 
> 
> So we decided to extended dummynet/ipfw to support packet classification in
> userspace.
> 
> Our idea is to extended socket structure to have a pipe number and have a
> setsockoption to associate the pipe number to a socket structure. Then have
> a new ipfw target (mappedpipe), which will pass the packet to dummynet
> (similar to pipe target) but with the pipe number in the socket structure if
> it is non-zero.
> 
> 
> 
> I would like to know your comments on this proposal and if people are
> interested, I will be happy to submit a patch on this.

i think the feature is useful. However I would implement it as an
ipfw 'option' called "sockarg" (or similar) as follows:

	ipfw pipe tablearg sockarg

where 'sockarg' succeeds ONLY if the packet is associated to a socket
for which the special setsockoption has been issued, and in this
case sets the 'tablearg' to the value of the setsockopt. This is
somewhat similar to the 'uid' and 'gid' options (except for setting
tablearg).  This way the mechanism can be very general (not limited
to pipes) and the implementation is probably
simpler than the one you propose.

In terms of runtime costs, we can look at check_uidgid() function,
and there are two ways to implement this feature:
- as in check_uidgid() , actively lookup for a matching socket if one
  is not available. This is expensive but would allow the feature to
  match also incoming packets;
- only match if the args->inp parameter is non-null, otherwise do not
  call in_pcblookup_hash(). This is cheaper but clearly only works
  for locally generated packets.
Perhaps we could use an argument for 'sockarg' so we can decide
whether to call or not the in_pcblookup_hash() on a case-by-case
basis.

cheers
luigi