[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+mtBx9SQDz9WOZAEQUXu+D=+ZizfbEHxMCM_gduYYTyOp=Jig@mail.gmail.com>
Date: Fri, 26 Sep 2014 12:56:43 -0700
From: Tom Herbert <therbert@...gle.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/5] udp: Generalize skb_udp_segment
On Fri, Sep 26, 2014 at 12:39 PM, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> On Fri, Sep 26, 2014 at 9:22 AM, Tom Herbert <therbert@...gle.com> wrote:
>> skb_udp_segment is the function called from udp4_ufo_fragment to
>> segment a UDP tunnel packet. This function currently assumes
>> segmentation is transparent Ethernet bridging (i.e. VXLAN
>> encapsulation). This patch generalizes the function to
>> operate on either Ethertype or IP protocol.
>
> this is great generalization.
> Do you envision that type_ether will cover vlan and mpls, right?
This design should allow providing GSO for any encapsulation of IP
protocol or Ethertype of UDP (as long as encapsulation headers don't
need to be modified for each segment). This actually covers quite a
lot of possibilities.
> What if somebody crazy adds a new thing after udp encap
> that is neither ethernet nor ip header?
> Like encryption header?
We could add an internal offloads table for that. This would entail a
new inner protocol type and then use inner_protocol to set offload
flavor which we can define. This also might be the path to some sort
of GSO for application layer protocols (like QUIC maybe...?)
> I think it would fit this model well...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists