Hello,
</snip>
> > >
> > > yes that's correct. the patch above comes from my private branch [1].
> > > mpi@ pointed out in off-line email exchange the patch unlocks local
> > > inbound
> > > packets too, which is coming bit early. However for forwarding case
> > > things
> > > seem to work (given all the panics I could see and fix).
> >
> > The way I understand Jono's question is: "Do we want this locking?". If
> > we decide that a single flow will always be processed by a single CPU,
> > is this necessary? If it isn't should we add an assert to document this
> > design decision?
>
> That's why I was asking. I'm not sure we want to make that guarantee, or at
> least not until we have a better idea of how rx hashing and things like tunnel
> protocols and nat interact. Using atomics here seems like a reasonable way to
> defer that and allow progress in pf.
>
> Are there other side-effects from pf_test() that we'll have to worry about?
>
OK, thanks for clarification. We might hit similar assert in
pf_state_key_link_inpcb(). I have not seen a panic there, but I was not
playing with local bound traffic as there are perhaps more dragons hiding
there.
I understand the advantage of putting same flows to same CPUs/cores. In
this case leaving pf_state_key_link_reverse() as-is makes sense. I'm sure
we can defer the decision whether take it or leave it.
> least not until we have a better idea of how rx hashing and things like tunnel
> protocols and nat interact. Using atomics here seems like a reasonable way to
I'm not too much worried about rx hashing and tunnels. The tunnels, NAT and
rx hashing are nicely streamlined/aligned. The way I see interaction of
tunnels with NAT is a chain of calls to pf_test(), so those calls are
serialized w.r.t. to individual packets as packets get
encapsulated/decapsulated. Let there be tun0, which 'sits' on top of em0.
Then for the outbound packet the processing looks as follows:
10.1.1.1/24 @ tun0 ----> outbound packet intercepted by
by pf_test(). state either created
or matched. the state No 1 must be
something like:
10.1.1.x <-> a.b.c.d
|
|
V
tun0 encapsulates packet so it can get transported by
underlying NIC em0
|
|
V
192.168.1.1/24 @ em0 ----> outbound packet intercepted by
pf_test. state either created or
matched. The state No 2 must be
something like:
192.168.1.1 <-> a.b.c.d
|
|
V
packet leaves the box
There is no relation between states No 1 and No 2, PF just sees them
as two unrelated sessions. So if it comes to rx-hashing the hashing
will have to make sure the outbound packet will end up at right
CPU. As it moves from tun0 to em0. The NAT does not change things
much, it has just influence on routing decision when packet
is being forwarded. But forwarding decision is yet another action
happening on the way.
I'm more worried about policy based routing (route-to/reply-to) vs.
rx-hashing. PBR can twist things in funny manner.
thanks and
regards
sashan
