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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
