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