Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

4 messages, 3 authors, 2002-09-28 · open the first message on its own page

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

From: James Morris <hidden>
Date: 2002-09-26 15:22:50

On Wed, 25 Sep 2002, David S. Miller wrote:
If you have things that must happen in a sequence to flow through
your path properly, that's where the "stackable" bit comes in.  You
do that one bit, skb->dst = dst_pop(skb->dst), then your caller
will pass the packet on to skb->dst->{output,input}().

Is it clearer now the kind of things you'll be able to do?
So, this could be used for generic network layer encapsulation, and be 
used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
use?  Sounds nice.


- James
-- 
James Morris
[off-list ref]

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

From: David S. Miller <hidden>
Date: 2002-09-26 20:54:06

   From: James Morris [off-list ref]
   Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST)
   
   So, this could be used for generic network layer encapsulation, and be 
   used for GRE tunnels, SIT etc. without the kinds of kludges currently in 
   use?  Sounds nice.

Such IPIP tunnels have very real problems though, since only 64-bits
of packet quoting are required in ICMP errors, it is often impossible
to deal with PMTU requests properly, see "#ifndef
I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

From: jamal <hidden>
Date: 2002-09-27 14:14:25


Dave,

now that i followed the thread on lk (slrn is great; thanks Jason);
I am actually interested to find out how you are going to pull what
you propose ;-> There are not that many things that will work well
with a dst-cache like idea. I actually considered the stacking idea
when i first was trying to prototype code that i posted. It is much harder
to make use of in practise. At least this is my experience.
If you look at the scheme i posted, youll see that the policy
could be to direct the packets to a IPV4-forwarding block or
totaly bypass it etc (i just didnt wanna jump into that step yet sicne it
is quiet involved architecturaly)
In any case we need to encourage people like the hipac authors to be
putting out things (i only wish theyd incorporate it into the tc
framework!); whatever changes made should consider that there is
more than one way to do things and people will always come with better
ways to do certain portions of the packet path.

cheers,
jamal

On Thu, 26 Sep 2002, David S. Miller wrote:
   From: James Morris [off-list ref]
   Date: Fri, 27 Sep 2002 01:27:41 +1000 (EST)

   So, this could be used for generic network layer encapsulation, and be
   used for GRE tunnels, SIT etc. without the kinds of kludges currently in
   use?  Sounds nice.

Such IPIP tunnels have very real problems though, since only 64-bits
of packet quoting are required in ICMP errors, it is often impossible
to deal with PMTU requests properly, see "#ifndef
I_WISH_WORLD_WERE_PERFECT" in net/ipv4/ip_gre.c

Re: [ANNOUNCE] NF-HIPAC: High Performance Packet Classification for Netfilter

From: David S. Miller <hidden>
Date: 2002-09-28 01:32:09

   From: jamal [off-list ref]
   Date: Fri, 27 Sep 2002 10:12:26 -0400 (EDT)
   
   whatever changes made should consider that there is more than one
   way to do things and people will always come with better ways to do
   certain portions of the packet path.

Of course.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help