IMHO, this should be inlines.

static inline int
pf_aeq(struct pf_addr *a, struct pf_addr *b, sa_family_t af)
{

switch (af) {
case AF_INET:
  return (a->addr32[0] == b->addr32[0]);
case AF_INET6:
  return ....
 default:
  panic()

}

The struct pf_addr should have anonymous union. After these two changes done, we would be able to more effectively use compiler and debugger.

I would consider that a further change, and might consider that after this is done.

So while we could make that an inline, and, I think, remove all the redundant copies (as I don't find any macro calls that DON'T pass the AF) to be done "right" will require a much larger change to the underlying C code. If we're truly in a position never to go back to pull in a new PF from OpenBSD then that's OK, but I want some discussion here on that topic first, before I go and rototill the other 100 lines that call these macros.

The description (short) for the review is really bad (mention at least pf(4) next time), and also a description of what is trying to be achieved would help massively (a commit message draft for example).

Looking at how much this would effect the main pf.c code if I were to change these to inline functions, I am going to leave this change as is, keep the macros and come back to this later when I do another (longer) pass over the pf code.

If we're truly in a position never to go back to pull in a new PF from OpenBSD then that's OK,
but I want some discussion here on that topic first, before I go and rototill the other 100 lines that call these macros.

If you consider pulling pf from OpenBSD, I'd suggest you to first dive deeper in this topic.

1. Compare difference between network stacks. Estimate complexity. First just in terms of APIs. Second, take in mind that we got SMP network stack and SMP pf, while OpenBSD neither.
2. Explain what are the killer features of new pf comparing to pf from OpenBSD 4.9. What are we actually aiming at?

I actually meant OpenBSD 4.5. This is the version we forked off. Btw, it used to be one of the fastest in OpenBSD itself.

http://quigon.bsws.de/papers/2011/pf10yrs/mgp00076.html