From: Harald Welte <laforge@netfilter.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org, Marcel Holtmann <marcel@holtmann.org>,
netfilter-devel@lists.netfilter.org, wensong@linux-vs.org
Subject: Re: [PATCH] reduce netfilte sk_buff enlargement
Date: Wed, 20 Jul 2005 09:23:05 -0400 [thread overview]
Message-ID: <20050720132305.GA4077@rama> (raw)
In-Reply-To: <20050718.203145.105430424.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Mon, Jul 18, 2005 at 08:31:45PM -0700, David S. Miller wrote:
> From: Harald Welte <laforge@netfilter.org>
> Date: Mon, 18 Jul 2005 00:04:51 +0200
>
> > The only real in-tree user of nfcache was IPVS, who only needs a single
> > bit. Unfortunately I couldn't find some other free bit in sk_buff to
> > stuff that bit into, so I introduced a separate field for them. Maybe
> > the IPVS guys can resolve that to further save space.
>
> I think we must resolve this one before 2.6.14 goes out, which
> gives us a lot of time, but for now I'll eat that one-bit member.
Well, I hope IPVS people will take care of this. I don't really know
that code too well...
> > Initially I wanted to shrink pkt_type to three bits (PACKET_HOST and
> > alike are only 6 values defined), but unfortunately the bluetooth code
> > overloads pkt_type :(
>
> This also must be cured somehow, that really isn't a clean nor nice
> usage of this field.
I just ran into Marcel Holtmann earlier today. He thinks moving that
data into the cb is fine, though he has to double-check that.
He also said that he really only needs 5 bits, so even if the current
pkt_type overloading would persist, we could probably shrink it to make
space for the IPVS bit.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-20 13:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-16 21:40 [PATCH] reduce netfilte sk_buff enlargement Harald Welte
2005-07-19 3:31 ` David S. Miller
2005-07-19 7:18 ` Jan Engelhardt
2005-07-19 7:23 ` David S. Miller
2005-07-20 13:23 ` Harald Welte [this message]
2005-07-20 15:43 ` Wensong Zhang
2005-07-20 21:35 ` Patrick McHardy
2005-07-20 18:43 ` David S. Miller
2005-07-21 18:20 ` Marcel Holtmann
2005-07-21 20:12 ` David S. Miller
2005-07-21 21:42 ` Marcel Holtmann
2005-07-21 22:10 ` David S. Miller
2005-07-21 22:29 ` David S. Miller
2005-07-21 23:49 ` Marcel Holtmann
2005-07-21 23:52 ` David S. Miller
2005-07-22 0:26 ` Marcel Holtmann
2005-07-22 22:54 ` David S. Miller
2005-07-23 1:36 ` Marcel Holtmann
2005-07-25 2:18 ` David S. Miller
2005-07-22 8:34 ` Amin Azez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050720132305.GA4077@rama \
--to=laforge@netfilter.org \
--cc=davem@davemloft.net \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=wensong@linux-vs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.