Date: Thu, 19 Aug 2010 17:44:26 -0700 From: Patrick Mahan <PMahan@adaranet.com> To: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Cc: "mahan@mahan.org" <mahan@mahan.org> Subject: PF newbie questions Message-ID: <32AB5C9615CC494997D9ABB1DB12783C024C875098@SJ-EXCH-1.adaranet.com>
next in thread | raw e-mail | index | archive | help
All, I am programmer tasked with investigating the use of ALTQ with our software as a QoS mechanism. However, my current investigation is from just what the Packet Filter (PF) code is doing. I am currently looking at the packet classification occurring in the IPv4 output function (ip_output.c::ip_output()) which leads to (pf_ioctl.c::pf_check_out()). pf_check_out() calls pf_test() which in turns calls pf_normalize_ip() which looks to me to perform a re-assembly of IP fragments. Note that I am only going on a code review. I have not yet gotten a test bed that I can run using the kernel debugger. I am just a little concern over the potential for impact to the throughput by the re-assembling of an IP packet from its fragments (which would then be re-fragmented when it is transmitted later in ip_output()). Also, I noticed that when an interface is initialized for ALTQ, the ifq_drv_maxlen is set to 0. I sort of understand this having worked for Cisco for a few years of my existence and seeing how the internal hardware queues were throttled when software queues were enabled on an interface. However, it seems to me that limiting it to 0 is a bit drastic. Shouldn't it be something like 4-8 packet limit? Thanks for your patience, Patrick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32AB5C9615CC494997D9ABB1DB12783C024C875098>