Date: Thu, 8 Oct 2009 00:54:52 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Joe R <apauljoe@gmail.com> Cc: freebsd-ipfw@freebsd.org, julian@elischer.org Subject: Re: Extension of dummynet/ipfw to support userspace packet classification Message-ID: <20091007225452.GA37005@onelab2.iet.unipi.it> In-Reply-To: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com> References: <286e18280910071246r33d33476ya9dd846cd1de6062@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091007225452.GA37005>