On Thu, Apr 05, 2012 at 07:11:36PM -0700, Jesse Gross wrote:
> On Thu, Apr 5, 2012 at 7:05 PM, Simon Horman <ho...@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 <ho...@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 <ho...@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
