On Thu, Apr 21, 2016 at 9:43 AM, Thadeu Lima de Souza Cascardo
wrote:
> On Wed, Apr 20, 2016 at 11:38:31AM -0700, Jesse Gross wrote:
>> One minor comment that I noticed on the patch itself - I don't know if
>> the port mapping functions are handling IPsec variants of tunnels
>> correctly in all si
On Wed, Apr 20, 2016 at 11:38:31AM -0700, Jesse Gross wrote:
> Thanks for that analysis. I agree with you that this looks safe. I'm
> glad - there are fewer corner cases than I was expecting.
>
> One minor comment that I noticed on the patch itself - I don't know if
> the port mapping functions ar
On Wed, Apr 20, 2016 at 4:00 AM, Thadeu Lima de Souza Cascardo
wrote:
> On Tue, Apr 19, 2016 at 04:25:32PM -0700, Jesse Gross wrote:
>> On Mon, Apr 18, 2016 at 2:57 AM, Thadeu Lima de Souza Cascardo
>> wrote:
>> > On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
>> >> On Fri, Apr 15,
On Tue, Apr 19, 2016 at 04:25:32PM -0700, Jesse Gross wrote:
> On Mon, Apr 18, 2016 at 2:57 AM, Thadeu Lima de Souza Cascardo
> wrote:
> > On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
> >> On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
> >> wrote:
> >> > Hi, this i
On Mon, Apr 18, 2016 at 2:57 AM, Thadeu Lima de Souza Cascardo
wrote:
> On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
>> On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
>> wrote:
>> > Hi, this is an RFC patch (could probably be 2 patches - more below), that
>> > crea
On Tue, Apr 19, 2016 at 07:00:00PM +0200, Jiri Benc wrote:
> On Mon, 18 Apr 2016 11:30:43 -0700, Jesse Gross wrote:
> > (Even on new kernels I don't know how this would interact
> > with OVS tunnel ports that are not of type 'flow'. Would they also use
> > the compat code?)
>
> This is a very good
On Mon, 18 Apr 2016 11:30:43 -0700, Jesse Gross wrote:
> (Even on new kernels I don't know how this would interact
> with OVS tunnel ports that are not of type 'flow'. Would they also use
> the compat code?)
This is a very good point. Although, on the other hand, how much common
are tunnel ports w
On Mon, Apr 18, 2016 at 3:27 AM, Jiri Benc wrote:
> On Fri, 15 Apr 2016 20:36:51 -0700, Jesse Gross wrote:
>> I'm not too excited about this. It seems like it would be a regression
>> - currently OVSDB allows remote creation of tunnels, so it seems like
>> this would break existing setups if it al
On Mon, Apr 18, 2016 at 12:36:31PM +0200, Jiri Benc wrote:
> On Mon, 18 Apr 2016 06:57:22 -0300, Thadeu Lima de Souza Cascardo wrote:
> > But... wait a minute. We don't support adding devices name as vxlan_sys*.
> > Such
> > names are reserved. I think that means we could probably rely on the name
On Mon, 18 Apr 2016 06:57:22 -0300, Thadeu Lima de Souza Cascardo wrote:
> I don't see how this address the case when the user adds a vxlan interface
> created by the system. Like:
>
> ip link add vxlan_sys_4789 type vxlan id 10 remote 192.168.123.1 dstport 4789
> ovs-vsctl add-port br0 vxlan_sys_
On Fri, 15 Apr 2016 20:36:51 -0700, Jesse Gross wrote:
> What about using the driver name exposed through ethtool? I believe
> that all of the tunnel and internal devices expose this in a
> consistent way - i.e. a VXLAN device can be queried and get back the
> string "vxlan". Any driver other than
On Fri, 15 Apr 2016 18:30:59 -0300, Thadeu Lima de Souza Cascardo wrote:
> Jiri has suggested that we require users to create the interfaces themselves,
> by
> using whatever method their OS has, and add them as netdev devices. That would
> still require fetching some of the configuration from the
On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
> On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
> wrote:
> > Hi, this is an RFC patch (could probably be 2 patches - more below), that
> > creates VXLAN devices in userspace and adds them as netdev vports, instead
> > o
On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
wrote:
> Hi, this is an RFC patch (could probably be 2 patches - more below), that
> creates VXLAN devices in userspace and adds them as netdev vports, instead of
> using the vxlan vport code.
>
> The reason for this change is that it
Hi, this is an RFC patch (could probably be 2 patches - more below), that
creates VXLAN devices in userspace and adds them as netdev vports, instead of
using the vxlan vport code.
The reason for this change is that it has been mentioned in the past that some
of the vport code should be considered
15 matches
Mail list logo
