Re: pf(4) status in 7.0-R

Max Laier wrote:
> On Friday 01 June 2007, Greg Hennessy wrote:
> 
>>>ditto.  I'd like to import a couple of features on a per-feature base
>>>rather than doing a complete import which isn't possible anymore due
>>>to SMP and routing code changes.
>>
>>Is the inability to completely sync PF with the latest OpenBSD release
>>cast in stone for here on, or it an issue of resource to do ?
>>
>>Just curious in light of recent PF improvements as detailed here
>>
>>http://www.undeadly.org/cgi?action=article&sid=20070528213858
> 
> This is a completely unrelated issue really.  Is debateable if it is good 
> practice to put all that information into the pkthdr, but the speed 
> improvement is something for sure.  It remains to be seen if FreeBSD's 
> mbuf tags perform as badly as OpenBSD's and - if they do - what can be 
> done about that.  One thing to keep in mind, however, pf is not the one 
> and only Firewall in FreeBSD and there are *many* other places that use 
> mbuf tags, too.  I would rather look for a more general optimization of 
> the mbuf tag framework - if required - , than gluttering the m_pkthdr 
> with all fields one can think of (pf, ipfw, ipf, vlans, ipsec, altq ...)

I don't think it is appropriate to put pf specific flags and pointers
into out mbuf header.  Optimizations that may help is to make a UMA zone
for the pf mtags, or - a bit hacky - use the remaining space in the mbuf
when a cluster is attached (almost always the case for inbound packets).

-- 
Andre