>>
>> That is always been behavior of the port lifecycle. If you remove the
>> driver of a device, port is removed from kernel datapath and the
>> device is deleted from kernel networking stack. For example you can
>> remove intel NIC driver, or veth module even if there is a
>> corresponding port
On 13 November 2017 at 05:01, Pravin Shelar wrote:
> On Sat, Nov 11, 2017 at 11:53 PM, Guru Shetty wrote:
> > On 10 November 2017 at 22:54, Gregory Rose wrote:
> >
> >> On 11/11/2017 9:57 AM, William Tu wrote:
> >>
> >>> yes, this is an
On Mon, Nov 13, 2017 at 5:01 AM, Pravin Shelar wrote:
> On Sat, Nov 11, 2017 at 11:53 PM, Guru Shetty wrote:
>> On 10 November 2017 at 22:54, Gregory Rose wrote:
>>
>>> On 11/11/2017 9:57 AM, William Tu wrote:
>>>
yes, this is an
On Sat, Nov 11, 2017 at 11:53 PM, Guru Shetty wrote:
> On 10 November 2017 at 22:54, Gregory Rose wrote:
>
>> On 11/11/2017 9:57 AM, William Tu wrote:
>>
>>> yes, this is an artificial dependency. Another way I'm thinking is for
> ovs-vswitchd
> to
On 11/12/2017 3:23 AM, Guru Shetty wrote:
On 10 November 2017 at 22:54, Gregory Rose > wrote:
On 11/11/2017 9:57 AM, William Tu wrote:
yes, this is an artificial dependency. Another way I'm
thinking is
On 10 November 2017 at 22:54, Gregory Rose wrote:
> On 11/11/2017 9:57 AM, William Tu wrote:
>
>> yes, this is an artificial dependency. Another way I'm thinking is for
ovs-vswitchd
to hold the geneve.ko dependency instead of openvswitch.ko, when user
On 11/11/2017 9:57 AM, William Tu wrote:
yes, this is an artificial dependency. Another way I'm thinking is for
ovs-vswitchd
to hold the geneve.ko dependency instead of openvswitch.ko, when user creates
a geneve device. Is there a way to do that through rtnetlink or at
>> yes, this is an artificial dependency. Another way I'm thinking is for
>> ovs-vswitchd
>> to hold the geneve.ko dependency instead of openvswitch.ko, when user
>> creates
>> a geneve device. Is there a way to do that through rtnetlink or at
>> dpif_netlink_rtnl_create()?
>
> It should be
On Fri, Nov 10, 2017 at 10:01:29AM -0800, William Tu wrote:
> On Fri, Nov 10, 2017 at 7:54 AM, Eric Garver wrote:
> > On Fri, Nov 10, 2017 at 05:36:25AM -0800, William Tu wrote:
> >> Before we introduce dpif-netlink-rtnl, creating a tunnel device
> >> depends on openvswitch/vport
On Fri, Nov 10, 2017 at 12:23:37PM -0800, William Tu wrote:
> >> After the dpif-netlink-rtnl, a tunnel device can be created by using
> >> rtnetlink, so the creation of fb device comes from the ovs-vswitchd
> >> instead of going through OVS kernel modules. This breaks the module
> >> dependency
On Fri, Nov 10, 2017 at 7:54 AM, Eric Garver wrote:
> On Fri, Nov 10, 2017 at 05:36:25AM -0800, William Tu wrote:
>> Before we introduce dpif-netlink-rtnl, creating a tunnel device
>> depends on openvswitch/vport kernel module calling kernel's tunnel API.
>> Example call sequence:
On 10 November 2017 at 07:54, Eric Garver wrote:
> On Fri, Nov 10, 2017 at 05:36:25AM -0800, William Tu wrote:
> > Before we introduce dpif-netlink-rtnl, creating a tunnel device
> > depends on openvswitch/vport kernel module calling kernel's tunnel API.
> > Example call sequence:
On Fri, Nov 10, 2017 at 05:36:25AM -0800, William Tu wrote:
> Before we introduce dpif-netlink-rtnl, creating a tunnel device
> depends on openvswitch/vport kernel module calling kernel's tunnel API.
> Example call sequence:
> 1) ovs_vport_add (openvswitch.ko)
> 2) geneve_create
13 matches
Mail list logo