I found this file in my $HOME. Anybody can comment on it ?
=== cut here ===
Description:
Following a email posted on linux kernel mailing list, there is a performance issue
in netfilter code path and zerocopy code path in 2.4.4 linux kernel.
A zerocopy skb (non-linear) is converted to linear skb and further degrades the
performance
of zerocopy path. This patch fixes the performance issue by setting a flag in
netfilter hook and
by passing non-linear skbs to netfilter hooks. Please review it and pass your
comments. Please accept the fix.
Regards
Ravi Chamarti
mailing list response:
---------------------------------------------------------------
Re: Ref: zerocopy +netfilter performance problem.
From: Ravi Chamarti ([EMAIL PROTECTED])
Date: Thu Oct 18 2001 - 13:41:24 EST
Next message: Urban Widmark: "Re: SMB compile problems"
Previous message: Tim Bird: "Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL"
Next in thread: [EMAIL PROTECTED]: "Re: Ref: zerocopy +netfilter performance
problem."
Reply: [EMAIL PROTECTED]: "Re: Ref: zerocopy +netfilter performance problem."
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
Hi,
Thanks for your response Alexey. I appreciate it.
--- [EMAIL PROTECTED] wrote:
> Hello!
>
> > My question is that is this copy is required for
> > netfilter to work? Do we somehow get around
> > with netfilter to work such that the zerocopy path
> > passes the packet without any copy?
>
> Yes & yes.
>
> Existing netfilter modules do not understand
> fragmented skbs,
> and as soon as netfilter folks are lazy even to move
> the check
> to relevant modules, even smart hooks has to be
> harmed by this.
How many netfilter modules exist which do not
understand fragmented skbs and need to look at the
skb data?
Will the following approach work?
if the somehow hook register shows interest only in
header (by setting a flag, may be in nf_hooks_ops
struct), then we can avoid the copy of the fragmented
skb's data and all other cases, we copy fragmented
skb's data to a kernel buffer. The side effect is that
a flag field is introduced into nf_hook_ops struct
which makes netfilter modules to recompile. Are there
any other side affects or better approaches?
regards
Ravi Chamarti
----------------------------------------------------------------------
Re: Ref: zerocopy +netfilter performance problem.
From: [EMAIL PROTECTED]
Date: Thu Oct 18 2001 - 13:47:46 EST
Next message: Neulinger, Nathan: "Promise SuperTrak 100/SX6000 support?"
Previous message: Gregory Ade: "2.2.x process limits (NR_TASKS)?"
In reply to: Ravi Chamarti: "Re: Ref: zerocopy +netfilter performance problem."
Next in thread: Martin Devera: "Re: sendto syscall is slow"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
--------------------------------------------------------------------------------
Hello!
> How many netfilter modules exist which do not
All of them.
> if the somehow hook register shows interest only in
> header
All the headers except for IP header can be split, at least
defragmenter generates them.
So, not this but rather: "does it understand that skb may be not linear?"
It will work of course.
Alexey
-
diff -urN -X dontdiff linux-vanilla/include/linux/netfilter.h
linux-2.4.4/include/linux/netfilter.h
--- linux-vanilla/include/linux/netfilter.h Mon Apr 30 10:06:19 2001
+++ linux-2.4.4/include/linux/netfilter.h Wed Feb 6 16:14:17 2002
@@ -51,6 +51,8 @@
int hooknum;
/* Hooks are ordered in ascending priority. */
int priority;
+#define NF_PKT_HDR_ONLY 0x0001
+ unsigned int flags;
};
struct nf_sockopt_ops
diff -urN -X dontdiff linux-vanilla/net/core/netfilter.c
linux-2.4.4/net/core/netfilter.c
--- linux-vanilla/net/core/netfilter.c Mon Apr 30 10:06:26 2001
+++ linux-2.4.4/net/core/netfilter.c Wed Feb 6 15:57:06 2002
@@ -332,6 +332,25 @@
return nf_sockopt(sk, pf, val, opt, len, 1);
}
+static int nf_skb_copy_packet(struct sk_buff *skb,
+ const struct net_device *outdev)
+{
+
+ /* This stopgap cannot be removed until all the hooks are audited. */
+ if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC) != 0) {
+ kfree_skb(skb);
+ return -ENOMEM;
+ }
+ if (skb->ip_summed == CHECKSUM_HW) {
+ if (outdev == NULL) {
+ skb->ip_summed = CHECKSUM_NONE;
+ } else {
+ skb_checksum_help(skb);
+ }
+ }
+ return 0;
+}
+
static unsigned int nf_iterate(struct list_head *head,
struct sk_buff **skb,
int hook,
@@ -340,8 +359,18 @@
struct list_head **i,
int (*okfn)(struct sk_buff *))
{
+ int ret = 0;
for (*i = (*i)->next; *i != head; *i = (*i)->next) {
struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;
+
+ /*
+ * If the hook wants data also and if there are skb frag list
+ * then copy the frag list into a packet
+ */
+ if (!(elem->flags & NF_PKT_HDR_ONLY))
+ if ((ret = nf_skb_copy_packet(*skb, outdev)) < 0)
+ return ret;
+
switch (elem->hook(hook, skb, indev, outdev, okfn)) {
case NF_QUEUE:
return NF_QUEUE;
@@ -450,19 +479,6 @@
struct list_head *elem;
unsigned int verdict;
int ret = 0;
-
- /* This stopgap cannot be removed until all the hooks are audited. */
- if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC) != 0) {
- kfree_skb(skb);
- return -ENOMEM;
- }
- if (skb->ip_summed == CHECKSUM_HW) {
- if (outdev == NULL) {
- skb->ip_summed = CHECKSUM_NONE;
- } else {
- skb_checksum_help(skb);
- }
- }
/* We may already have this, but read-locks nest anyway */
br_read_lock_bh(BR_NETPROTO_LOCK);
--
Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar
PPKJ1-RIPE // (smtp)[EMAIL PROTECTED] // (http)stingr.net // (pgp)0xA4B4ECA4
