Patrick McHardy wrote:
> Kazunori Miyazawa wrote:
> 
>>Hello Patrick,
>>
>>I have a comment about the patch on the IPv6 input process.
>>The kernel applied your patch will always call ip6_rcv_finish
>>when enabling netfilter and receiving a esp packet so that
>>it will always look up the routing table and parse
>>extention headers twice a packet.
>>It will probably cost.
>>
>>Your ip_xfrm_transport_hook is a good idea, I think.
> 
> 
> Yes, not passing the packets through the entire stack seems like
> the right thing to do.
> 
> 
>>We could call ip6_rcv_finish if the netfilter changed the addresses
>>or otherwise we can continue the loop to avoid the cost in a similar
>>way because we can know the change with checking skb->dst.
>>
>>If you fix the point, your change will resolve our issues which were
>>mentioned in the previous mail from Kozakai-san.
> 
> 
> The problem is that netfilter hooks take ownership of the skb, so the
> caller can't touch it afterwards. It would be possible, but it would
> become very ugly. Can I assume that you would also be satisfied if
> the double-parsing of extension headers is fixed in some other way?

My concern is cost to look up routing table and parse extention headers twice.
I think the latter will be critical issue if some extention header makes
some state in the stack.

IMHO, we will call the loop part of ip6_input_finish to inject the skb
to upper layer directly in ip6_xfrm_transport_hook.
But it may make duplicate codes and raise other issues...

I'm also consider the issue.

Thank you Patrick,

--
Kazunori Miyazawa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to