netdev - Re: [net-next 00/10] Add Geneve

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACzMAJKyXaO0CL5XOnH7cHOk3voz_shVaK6Jmd0mx0h2NBtn-w@mail.gmail.com>
Date:	Thu, 24 Jul 2014 14:03:48 -0700
From:	Andy Zhou <azhou@...ira.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Or Gerlitz <or.gerlitz@...il.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-next 00/10] Add Geneve

@or.gerlitz@...il.com:  Yes, this is the logical order of the patch
series. I can improve the cover letter to make it clearer.


@therbert@...gle.com: I will add L2TP refactor to the series in the
next version. Given that port number and associated protocol is still
required
by NIC device driver for advanced offloads, we may still need to
define the protocol types. Are you O.K. with this, if not, any other
suggestions?

On Thu, Jul 24, 2014 at 10:40 AM, Tom Herbert <therbert@...gle.com> wrote:
> On Wed, Jul 23, 2014 at 11:58 PM, Or Gerlitz <or.gerlitz@...il.com> wrote:
>> On Tue, Jul 22, 2014 at 1:19 PM, Andy Zhou <azhou@...ira.com> wrote:
>>> Following patches adds initial support for Geneve tunnel protocol
>>
>> Just to make this a bit more clear, would it be correct to say that
>> the logical ordering here is as follows:
>>
> Agreed, improvements to the general infrastructure to support UDP
> tunneling should be done first. This was already begun with
> introduction of udp_tunnel.[ch] and the udp_tunnel_xmit functions seem
> like a nice addition at least.
>
> Also, we have at least two instances of UDP tunneling in the code that
> should addressed when interface improvements: VXLAN and L2TP. Please
> make sure *both* of these are considered with such patches (also the
> needs for Geneve, GUE, LISP, etc. should be considered, but please no
> protocol specific stuff in the common infrastructure code!)
>
>>> 1. Add common UDP tunnel code into UDP tunnel support function
>>> 2. Refactor vxlan driver to make use of the UDP tunnel support
>>> 3. Add Geneve driver.
>>
>> implemented by patches 1-5 below)
>>
>>> Andy Zhou (5):
>>>   net: Rename ndo_add_vxlan_port to ndo_add_udp_tunnel_port.
>>>   udp: Expand UDP tunnel common APIs
>>>   vxlan: Remove vxlan_get_rx_port()
>>>   net: Refactor vxlan driver to make use of common UDP tunnel functions
>>>   net: Add Geneve tunneling protocol driver
>>
>> and on top of that
>>
>>> 4. Refactor Openvswitch  in preparation for #5
>>> 5. Add Geneve support to Openvswitch.
>>
>> implemented by patches 6-10 (below)
>>
>>> Jesse Gross (5):
>>>   openvswitch: Eliminate memset() from flow_extract.
>>>   openvswitch: Add support for matching on OAM packets.
>>>   openvswitch: Wrap struct ovs_key_ipv4_tunnel in a new structure.
>>>   openvswitch: Factor out allocation and verification of actions.
>>>   openvswitch: Add support for Geneve tunneling.
>>
>> I understand the wish to eventually have something that goes beyond
>> refactoring of
>> the vxlan and tunneling code plus Geneve basics. However, isn't the
>> 1st part of the series
>> (patches 1-5) have something is common to Tom's GUE work, which is
>> currently under review
>> too? I think we need first see how the basic elements from your series
>> go along together with GUE.
>>
>> Or.
--
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