Re: offloading ip checksum calculation to the NIC
On Fri, Feb 03, 2006 at 03:07:03PM +0300, Gleb Smirnoff wrote: > On Fri, Feb 03, 2006 at 02:30:54AM -0800, kamal kc wrote: > k> so what do i need to do if i don't want to calculate > k> the ip checksum myself ? > k> > k> right now i am taking off packet from the kernel > k> and modifying some of the data content, and > k> outputting to the IFQ_HANDOFF myself. and i > k> am calculating the checksum myself. > k> > k> i guess if xl would support the > k> hardware checksumming i could use that > k> feature. > k> > k> i am just a beginner and i am not getting > k> the clear picture. > > If interfaces has enabled capabilities for checksum offloading, then > the kernel skips checksum calculation. > > See http://people.freebsd.org/~jlemon/csum.txt FWIW, the details of hardware-assisted checksumming are also documented on the mbuf(9) and ifnet(9) manpages. -- Yar ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_bridge.ko requires INET6...
On Thursday 02 February 2006 14:37, Max Laier wrote:
> On Thursday 02 February 2006 13:43, Yar Tikhiy wrote:
> > > This needs to be fixed in pf then.
> >
> > Max Laier and I discussed this issue once, and Max had concern
> > over possible performance degradation that might result from
> > calling pflog functions through pointers to be set by a separate
> > pflog module. We can skip touching the pf module in RELENG_6 for
> > now and leave the issue to after 6.1-RELEASE is out.
>
> I have convinced myself that we should really use a function pointer here.
> I will try to commit a sollution to HEAD over the weekend. If you are
> MFC'ing the changes *now*, I'd appreciate if you could spare out pf, but I
> am willing to MFC the changes before 6.1 if testing goes well.
Here it is. I'd appreciate feedback. pflog_packet() uses a lot of complex
types which makes it necessary to include pfvar.h. This is ugly, but I don't
know how to work around this.
--
/"\ Best regards, | [EMAIL PROTECTED]
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED]
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: contrib/pf/net/if_pflog.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pflog.c,v
retrieving revision 1.18
diff -u -r1.18 if_pflog.c
--- contrib/pf/net/if_pflog.c 5 Dec 2005 11:58:31 - 1.18
+++ contrib/pf/net/if_pflog.c 4 Feb 2006 15:09:11 -
@@ -376,9 +376,15 @@
case MOD_LOAD:
LIST_INIT(&pflog_list);
if_clone_attach(&pflog_cloner);
+ PF_LOCK();
+ pflog_packet_ptr = pflog_packet;
+ PF_UNLOCK();
break;
case MOD_UNLOAD:
+ PF_LOCK();
+ pflog_packet_ptr = NULL;
+ PF_UNLOCK();
if_clone_detach(&pflog_cloner);
break;
@@ -400,4 +406,5 @@
DECLARE_MODULE(pflog, pflog_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY);
MODULE_VERSION(pflog, PFLOG_MODVER);
+MODULE_DEPEND(pflog, pf, PF_MODVER, PF_MODVER, PF_MODVER);
#endif /* __FreeBSD__ */
Index: contrib/pf/net/if_pflog.h
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/if_pflog.h,v
retrieving revision 1.6
diff -u -r1.6 if_pflog.h
--- contrib/pf/net/if_pflog.h 10 Jun 2005 16:49:03 - 1.6
+++ contrib/pf/net/if_pflog.h 4 Feb 2006 15:08:59 -
@@ -70,10 +70,24 @@
#ifdef _KERNEL
+#ifdef __FreeBSD__
+/* XXX */
+#include
+
+typedef int pflog_packet_t(struct pfi_kif *, struct mbuf *, sa_family_t,
+u_int8_t, u_int8_t, struct pf_rule *, struct pf_rule *,
+struct pf_ruleset *);
+extern pflog_packet_t *pflog_packet_ptr;
+#define PFLOG_PACKET(i,x,a,b,c,d,e,f,g) do { \
+ if (pflog_packet_ptr != NULL) \
+ pflog_packet_ptr(i,a,b,c,d,e,f,g); \
+} while (0)
+#else
#if NPFLOG > 0
#define PFLOG_PACKET(i,x,a,b,c,d,e,f,g) pflog_packet(i,a,b,c,d,e,f,g)
#else
#define PFLOG_PACKET(i,x,a,b,c,d,e,f,g) ((void)0)
#endif /* NPFLOG > 0 */
+#endif /* __FreeBSD__ */
#endif /* _KERNEL */
#endif /* _NET_IF_PFLOG_H_ */
Index: contrib/pf/net/pf_ioctl.c
===
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v
retrieving revision 1.22
diff -u -r1.22 pf_ioctl.c
--- contrib/pf/net/pf_ioctl.c 5 Dec 2005 11:58:31 - 1.22
+++ contrib/pf/net/pf_ioctl.c 4 Feb 2006 15:09:30 -
@@ -108,6 +108,10 @@
#include
#endif /* NPFSYNC > 0 */
+#ifdef __FreeBSD__
+#include
+#endif
+
#ifdef INET6
#include
#include
@@ -230,6 +234,7 @@
static volatile int pf_pfil_hooked = 0;
struct mtx pf_task_mtx;
+pflog_packet_t *pflog_packet_ptr = NULL;
void
init_pf_mutex(void)
Index: modules/Makefile
===
RCS file: /usr/store/mlaier/fcvs/src/sys/modules/Makefile,v
retrieving revision 1.472
diff -u -r1.472 Makefile
--- modules/Makefile 31 Jan 2006 23:11:35 - 1.472
+++ modules/Makefile 3 Feb 2006 22:57:36 -
@@ -180,6 +180,7 @@
pcn \
${_pecoff} \
${_pf} \
+ ${_pflog} \
plip \
${_pmc} \
portalfs \
@@ -307,6 +308,7 @@
.if !defined(NO_PF) || defined(ALL_MODULES)
_pf= pf
+_pflog= pflog
.endif
.if ${MACHINE_ARCH} == "i386"
Index: modules/pf/Makefile
===
RCS file: /usr/store/mlaier/fcvs/src/sys/modules/pf/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- modules/pf/Makefile 14 Oct 2005 23:30:14 - 1.8
+++ modules/pf/Makefile 3 Feb 2006 22:46:23 -
@@ -6,7 +6,6 @@
KMOD= pf
SRCS = pf.c pf_if.c pf_subr.c pf_osfp.c pf_ioctl.c pf_norm.c pf_table.c \
- if_pflog.c \
in4_cksum.c \
opt_pf.h opt_inet.h opt_inet6.h opt_bpf.h
@@ -15,7 +14,6 @@
.if !defined(KERNBUILDDIR)
opt_pf.h:
echo "#define DEV_PF 1" > opt_pf.h
- echo "#define DEV_PFLOG 1" >> opt_pf.h
opt_inet.h:
echo "#define INET 1" > opt_inet.h
Index: modules/pflog/Makefile
=
Re: freebsd 6.0 network card / route fail over question
On Fri, Feb 03, 2006 at 01:33:44PM -0600, Matthew Lineen wrote: > I'm trying to workout the specifics of NIC/route fail over on FreeBSD > 6.0 and hoped someone here could point me in the right direction. > > We have 2 ServerIron load balancers and each of our application servers > is plugged into both LBs. > > So, for example, an app server would have the following... > > bge0 IP of x.y.z.61 netmask 255.255.255.128 > bge1 IP of x.y.z.63 netmask 255.255.255.128 > > In /etc/rc.conf the default route is x.y.z.1 > > In the routing table, the default route uses Netif bge0. So, when we > turn off the first load balancer, bge0 goes down, but the default route > never "moves" from bge0. > > I assume this is because ... > > #1 - FreeBSD doesn't like having two interfaces bound to the same > x.y.z/25 network (we get plenty of the "arp: x.y.z.123 is on bge0 but > got reply from ... on bge1" messages) Correct. > #2 - The default route is bound to bge0 because bge0 is the first > interface that contains an IP in the same network as the default route's. > > So, my question is: what approaches do people take to solve this > problem? I've come across forwarding and carp, but I thought I'd ask > the list to see if there is something simple I'm missing, other ways of > handling this, etc... I don't see a simple alternative. The approaches I can see are: (1) The layer 2 approach. Try to make an ethernet bundle consisting of two links; a single IP address will be shared by both. I don't know if FreeBSD supports this, and in any case, it will almost certainly only work if the two uplinks go into the same switch. (2) The layer 3 approach. Assign bge0 and bge1 different IP addresses (preferably on two different subnets). Learn your default route via OSPF or RIP from the upstream router(s), using something like quagga. Given that the upstream devices are ServerIrons, which are really just fancy switches, this may not work, but maybe you can get a RIP defaultroute announcement out of them. (3) The layer 7 approach. On each server just have a *single* uplink into one of the two ServerIrons, and rely on your application failover mechanism. You presumably have multiple application servers, so if a whole server fails, everything keeps working properly, right? In that case, rely on this mechanism to cope with the case where your server's NIC or the cable or the upstream switch fails. Make sure half the servers are on one switch and half on the other, so if the whole switch fails, you still have half your servers reachable. And keep a spare switch in the closet. Method (3) is the one I've used successfully for a mailserver cluster. There were two MX receivers, two webmail servers, four POP3 servers; half on one uplink and half on the other. IMO it's at least as likely likely that a whole server will fail (bad PSU, failed hard drive etc) than the NIC or switch port fails. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Polling for ath driver
I've been working on polling for the FreeBSD ath wireless driver. On slow CPU's polling helps prevent (by supressing certain interrupts) livelock and increases throughput. This is true of Atheros cards on Soekris and other embedded hardware. Just thought I'd post something here in case anyone is interested in helping with insight, code or testing. I've got a rough (and mostly working) patch. There are some locking issues to contend with... Cheers, Nate ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wireless PCI for FreeBSD 6.0
I want to buy a wireless PCI adapter for a machine running FreeBSD 6.0. After reading the archives, man pages, etc. I realized that his is a tricky business. Some of the adaptors listed as supported have now a different chipset. For example, Netgear WG311T now has the AR5002G chipset and I guess this means it is no longer supported by the ath(4) driver. If you bought recently a wireless PCI adapter in the price range of the Netgear WG311T (less than $50) that was supported by the FreeBSD drivers (not the ndis wrapper), could you give me a shout? Thanks a lot! Lukas ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
