[ovs-dev] [PATCH] [RFC] [linux kernel patch] Add TCP encap_rcv hook

Simon Horman horms at verge.net.au
Fri Apr 6 02:15:26 UTC 2012


On Thu, Apr 05, 2012 at 07:11:36PM -0700, Jesse Gross wrote:
> On Thu, Apr 5, 2012 at 7:05 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Thu, Apr 05, 2012 at 06:47:23PM -0700, Jesse Gross wrote:
> >> On Thu, Apr 5, 2012 at 5:35 PM, Simon Horman <horms at verge.net.au> wrote:
> >> > On Thu, Apr 05, 2012 at 05:00:12PM -0700, Jesse Gross wrote:
> >> >> On Wed, Apr 4, 2012 at 6:08 PM, Simon Horman <horms at verge.net.au> wrote:
> >> >> > +               encap_rcv = ACCESS_ONCE(tp->encap_rcv);
> >> >> > +               if (encap_rcv) {
> >> >> > +                       int ret = encap_rcv(sk, skb);
> >> >> > +                       if (ret <= 0)
> >> >> > +                               return -ret;
> >> >>
> >> >> It seems odd to resubmit as a different protocol here.  With UDP it's
> >> >> common to have something that runs over either bare IP or encapsulated
> >> >> in UDP but I'm not sure that the same really applies here.
> >> >>
> >> >> > +               }
> >> >
> >> > Ok, so perhaps it would be best to just have
> >> >
> >> >        return encap_rcv(sk, skb);
> >> >
> >> > This was the behaviour of my original version of this patch but
> >> > I thought it may make sense to have behaviour closer to UDP's encap_rcv.
> >>
> >> I think there's probably still value in allowing the encap handler to
> >> reject the packet back to the TCP stack.
> >
> > Ok, in that case I'm not sure that I understood your point about different
> > protocols.
> 
> I think they're independent things.  UDP allows the encap handler to
> do one of three different things: take the packet, allow it to
> continue down the protocol stack, or interpret as the IP protocol in
> the return type.  I think the first two make sense in the context of
> the TCP handler but the third is odd because it's unlikely that a TCP
> encapsulated packet and a bare IP protocol will have a direct
> correlation.  Since I don't think it makes sense, I would just
> disallow it.

Thanks for the clarification. I agree that makes sense.



More information about the dev mailing list