On Sun, 24 May 2015 11:24:45 +0300, Alexander V. Chernikov wrote:
23.05.2015, 03:58, hiren panchasara hi...@strugglingcoder.info:
On 05/21/15 at 02:05P, hiren panchasara wrote:
On 05/21/15 at 12:42P, hiren panchasara wrote:
Getting back to this now to see if I can avoid ipfw on outgoing packets.
@@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf)
hook_func = (pf == AF_LINK) ? ipfw_check_frame :
ipfw_check_packet;
(void) (onoff ? pfil_add_hook : pfil_remove_hook)
- (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
+ (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
return 0;
}
Should this do the right thing? I'll report back once I test this patch.
I am still seeing ipfw_chk() getting called in my iperf test. Now, if I
also remove PFIL_IN, i.e if I do:
- (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
+ (hook_func, NULL, PFIL_WAITOK, pfh);
I don't see ipfw_chk() getting triggered.
Somehow incoming traffic is affecting the outgoing traffic?
It seems I screwed up something in testing and the following does seem to
do the
right thing:
- (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
+ (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting
called in OUT direction.
Any thoughts on this? Is this something that can be upstreamed with a
sysctl knob if there is interest?
Unfortunately, I've missed most of the thread.
First of all, just calling ipfw hook should not be so costy - I can
believe in 5% in 8/9/10, but the reason should be not ipfw, but
rwlock which is used ti protect ruleset.
HEAD version should behave better (we observe something like 1%
overhead on 10+mpps rate) since it uses rmlock.
That's certainly a big improvement.
Being able to attach/detach appropriate L3 hooks is really a good
idea, however the better (but not easier way) would be to implement
something like `pfilctl' utility which would be able to
control/disable/reorder hooks on particular filtering points (pf
before ipfw or vice versa). This stuff would also help to convert
some of the current L2 processing code to pfil (like
BPF,lagg,netgraph input hooks in eher_input)
Well ipfw already may be seeing L2 traffic via net.link.ether.ipfw; is
that already separate from the L3 pfil hooks? I haven't followed pfil.
The more generic way to link and order hooks sounds like a better idea
than needing to mess with ipfw (or pf, or anything) to accomplish that.
cheers, Ian (FWIW)
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
