* IPMARK nfcache
@ 2005-10-28 22:17 Alexander Samad
2005-10-29 16:53 ` Grzegorz Janoszka
0 siblings, 1 reply; 4+ messages in thread
From: Alexander Samad @ 2005-10-28 22:17 UTC (permalink / raw)
To: netfilter-devel; +Cc: Grzegorz Janoszka
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
Hi
Recently went to path IPMARK (Patchlet from patch o matic) to a 2.6.14
source tree and I have noticed this compilation error
net/ipv4/netfilter/ipt_IPMARK.c: In function 'target':
net/ipv4/netfilter/ipt_IPMARK.c:36: error: 'struct sk_buff' has no
member named 'nfcache'
net/ipv4/netfilter/ipt_IPMARK.c:36: error: 'NFC_ALTERED' undeclared
(first use in this function)
net/ipv4/netfilter/ipt_IPMARK.c:36: error: (Each undeclared identifier
is reported only once
net/ipv4/netfilter/ipt_IPMARK.c:36: error: for each function it appears
in.)
on investigation the nfcache field from sk_buff has been removed, having
a look on the net as to why
I was wondering what mechanism is need to replace the 'ncfcache |
NFC_ALTERED' statement
Seem like it has been killed - gives me the impression I can remove this
line with no bad side effects ?
commit 6869c4d8e066e21623c812c448a05f1ed931c9c6
Author: Harald Welte <laforge@netfilter.org>
Date: Tue Aug 9 19:24:19 2005 -0700
[NETFILTER]: reduce netfilter sk_buff enlargement
As discussed at netconf'05, we're trying to save every bit in
sk_buff.
The patch below makes sk_buff 8 bytes smaller. I did some basic
testing on my notebook and it seems to work.
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.
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 :(
The conntrack-event-api (out-of-tree) uses nfcache, but Rusty just
came up with a way how to do it without any skb fields, so it's safe
to remove it.
- remove all never-implemented 'nfcache' code
- don't have ipvs code abuse 'nfcache' field. currently get's their
own
compile-conditional skb->ipvs_property field. IPVS maintainers
can
decide to move this bit elswhere, but nfcache needs to die.
- remove skb->nfcache field to save 4 bytes
- move skb->nfctinfo into three unused bits to save further 4 bytes
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks
Alex
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: IPMARK nfcache
2005-10-28 22:17 IPMARK nfcache Alexander Samad
@ 2005-10-29 16:53 ` Grzegorz Janoszka
2005-10-29 17:12 ` Grzegorz Janoszka
0 siblings, 1 reply; 4+ messages in thread
From: Grzegorz Janoszka @ 2005-10-29 16:53 UTC (permalink / raw)
To: Alexander Samad; +Cc: netfilter-devel
On Sat, 29 Oct 2005, Alexander Samad wrote:
> Recently went to path IPMARK (Patchlet from patch o matic) to a 2.6.14
> source tree and I have noticed this compilation error
> net/ipv4/netfilter/ipt_IPMARK.c: In function 'target':
> net/ipv4/netfilter/ipt_IPMARK.c:36: error: 'struct sk_buff' has no
> member named 'nfcache'
> net/ipv4/netfilter/ipt_IPMARK.c:36: error: 'NFC_ALTERED' undeclared
> (first use in this function)
> on investigation the nfcache field from sk_buff has been removed, having
> a look on the net as to why
> I was wondering what mechanism is need to replace the 'ncfcache |
> NFC_ALTERED' statement
My IPMARK was based on original MARK target. You can look what has changed
in libipt_MARK.c and correct it.
I don't know if I have to submit a new patch or it will be corrected by
netfilter developers?
--
Grzegorz Janoszka
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IPMARK nfcache
2005-10-29 16:53 ` Grzegorz Janoszka
@ 2005-10-29 17:12 ` Grzegorz Janoszka
2005-10-30 5:49 ` Alexander Samad
0 siblings, 1 reply; 4+ messages in thread
From: Grzegorz Janoszka @ 2005-10-29 17:12 UTC (permalink / raw)
To: Alexander Samad; +Cc: netfilter-devel
On Sat, 29 Oct 2005, Grzegorz Janoszka wrote:
> My IPMARK was based on original MARK target. You can look what has changed in
> libipt_MARK.c and correct it.
http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2689
The patch dedicated to net/ipv4/netfilter/ipt_MARK.c should go to
ipt_IPMARK.c
> I don't know if I have to submit a new patch or it will be corrected by
> netfilter developers?
I suggest you make the changes, can you do it?
--
Grzegorz Janoszka
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: IPMARK nfcache
2005-10-29 17:12 ` Grzegorz Janoszka
@ 2005-10-30 5:49 ` Alexander Samad
0 siblings, 0 replies; 4+ messages in thread
From: Alexander Samad @ 2005-10-30 5:49 UTC (permalink / raw)
To: Grzegorz Janoszka; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Sat, Oct 29, 2005 at 07:12:44PM +0200, Grzegorz Janoszka wrote:
> On Sat, 29 Oct 2005, Grzegorz Janoszka wrote:
>
> >My IPMARK was based on original MARK target. You can look what has changed
> >in libipt_MARK.c and correct it.
>
> http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2689
>
> The patch dedicated to net/ipv4/netfilter/ipt_MARK.c should go to
> ipt_IPMARK.c
>
> >I don't know if I have to submit a new patch or it will be corrected by
> >netfilter developers?
>
> I suggest you make the changes, can you do it?
Cool, will give it a go!
>
> --
> Grzegorz Janoszka
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-10-30 5:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-28 22:17 IPMARK nfcache Alexander Samad
2005-10-29 16:53 ` Grzegorz Janoszka
2005-10-29 17:12 ` Grzegorz Janoszka
2005-10-30 5:49 ` Alexander Samad
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.