similar to: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice

On Wed, Apr 4, 2018 at 10:21 AM, David Ahern <dsahern at gmail.com> wrote: > On 4/4/18 1:36 AM, Siwei Liu wrote: >> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern at gmail.com> wrote: >>> On 4/3/18 9:42 AM, Jiri Pirko wrote: >>>>> >>>>> There are other use cases that want to hide a device from userspace. I >>>>

On Tue, Apr 3, 2018 at 6:04 PM, David Ahern <dsahern at gmail.com> wrote: > On 4/3/18 9:42 AM, Jiri Pirko wrote: >>> >>> There are other use cases that want to hide a device from userspace. I >> >> What usecases do you have in mind? > > As mentioned in a previous response some kernel drivers create control > netdevs. Just as in this case users should

Wed, Apr 04, 2018 at 03:04:26AM CEST, dsahern at gmail.com wrote: >On 4/3/18 9:42 AM, Jiri Pirko wrote: >>> >>> There are other use cases that want to hide a device from userspace. I >> >> What usecases do you have in mind? > >As mentioned in a previous response some kernel drivers create control >netdevs. Just as in this case users should not be mucking

From: David Ahern <dsahern at gmail.com> Date: Wed, 4 Apr 2018 11:37:52 -0600 > Networking vendors have out of tree kernel modules. Those modules use a > netdev (call it a master netdev, a control netdev, cpu port, whatever) > to pull packets from the ASIC and deliver to virtual netdevices > representing physical ports. The master netdev should not be mucked with > by a user.

On Wed, 4 Apr 2018 11:37:52 -0600 David Ahern <dsahern at gmail.com> wrote: > Networking vendors have out of tree kernel modules. Those modules use a > netdev (call it a master netdev, a control netdev, cpu port, whatever) > to pull packets from the ASIC and deliver to virtual netdevices > representing physical ports. The master netdev should not be mucked with > by a user.

Sun, Apr 01, 2018 at 06:11:29PM CEST, dsahern at gmail.com wrote: >On 4/1/18 3:13 AM, Si-Wei Liu wrote: >> Hidden netdevice is not visible to userspace such that >> typical network utilites e.g. ip, ifconfig and et al, >> cannot sense its existence or configure it. Internally >> hidden netdev may associate with an upper level netdev >> that userspace has access to.

On Sun, Apr 1, 2018 at 9:11 AM, David Ahern <dsahern at gmail.com> wrote: > On 4/1/18 3:13 AM, Si-Wei Liu wrote: >> Hidden netdevice is not visible to userspace such that >> typical network utilities e.g. ip, ifconfig and et al, >> cannot sense its existence or configure it. Internally >> hidden netdev may associate with an upper level netdev >> that

From: David Ahern <dsahern at gmail.com> Date: Wed, 4 Apr 2018 11:21:54 -0600 > It is a netdev so there is no reason to have a separate ip command to > inspect it. 'ip link' is the right place. I agree on this. What I really don't understand still is the use case... really. So there are control netdevs, what exactly is the problem with that? Are we not exporting enough

From: David Ahern <dsahern at gmail.com> Date: Wed, 4 Apr 2018 11:21:54 -0600 > It is a netdev so there is no reason to have a separate ip command to > inspect it. 'ip link' is the right place. I agree on this. What I really don't understand still is the use case... really. So there are control netdevs, what exactly is the problem with that? Are we not exporting enough

On Wed, Apr 4, 2018 at 10:37 AM, David Miller <davem at davemloft.net> wrote: > From: David Ahern <dsahern at gmail.com> > Date: Wed, 4 Apr 2018 11:21:54 -0600 > >> It is a netdev so there is no reason to have a separate ip command to >> inspect it. 'ip link' is the right place. > > I agree on this. I'm completely fine of having an API for

> Networking vendors have out of tree kernel modules. Those modules use a > netdev (call it a master netdev, a control netdev, cpu port, whatever) > to pull packets from the ASIC and deliver to virtual netdevices > representing physical ports. Sounds a lot like DSA. Please ask the vendor to contribute the drivers :-) > The master netdev should not be mucked with by a user. It

(put discussions back on list which got accidentally removed) On Tue, Apr 3, 2018 at 4:08 PM, Stephen Hemminger <stephen at networkplumber.org> wrote: > On Tue, 3 Apr 2018 12:04:38 -0700 > Siwei Liu <loseweigh at gmail.com> wrote: > >> On Tue, Apr 3, 2018 at 10:35 AM, Stephen Hemminger >> <stephen at networkplumber.org> wrote: >> > On Sun, 1 Apr

On Mon, 9 Apr 2018 15:30:42 -0700 Siwei Liu <loseweigh at gmail.com> wrote: > On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn <andrew at lunn.ch> wrote: > >> No, implementation wise I'd avoid changing the class on the fly. What > >> I'm looking to is a means to add a secondary class or class aliasing > >> mechanism for netdevs that allows mapping for

On Sun, Apr 8, 2018 at 9:32 AM, David Miller <davem at davemloft.net> wrote: > From: Siwei Liu <loseweigh at gmail.com> > Date: Fri, 6 Apr 2018 19:32:05 -0700 > >> And I assume everyone here understands the use case for live >> migration (in the context of providing cloud service) is very >> different, and we have to hide the netdevs. If not, I'm more

On 4/17/2018 5:26 PM, Siwei Liu wrote: > I ran this with a few folks offline and gathered some good feedbacks > that I'd like to share thus revive the discussion. > > First of all, as illustrated in the reply below, cloud service > providers require transparent live migration. Specifically, the main > target of our case is to support SR-IOV live migration via kernel >

On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn <andrew at lunn.ch> wrote: >> No, implementation wise I'd avoid changing the class on the fly. What >> I'm looking to is a means to add a secondary class or class aliasing >> mechanism for netdevs that allows mapping for a kernel device >> namespace (/class/net-kernel) to userspace (/class/net). Imagine >>

On Sun, 1 Apr 2018 05:13:09 -0400 Si-Wei Liu <si-wei.liu at oracle.com> wrote: > Hidden netdevice is not visible to userspace such that > typical network utilites e.g. ip, ifconfig and et al, > cannot sense its existence or configure it. Internally > hidden netdev may associate with an upper level netdev > that userspace has access to. Although userspace cannot >

From: Siwei Liu <loseweigh at gmail.com> Date: Fri, 6 Apr 2018 19:32:05 -0700 > And I assume everyone here understands the use case for live > migration (in the context of providing cloud service) is very > different, and we have to hide the netdevs. If not, I'm more than > happy to clarify. I think you still need to clarify. netdevs are netdevs. If they have special

From: Siwei Liu <loseweigh at gmail.com> Date: Fri, 6 Apr 2018 19:32:05 -0700 > And I assume everyone here understands the use case for live > migration (in the context of providing cloud service) is very > different, and we have to hide the netdevs. If not, I'm more than > happy to clarify. I think you still need to clarify. netdevs are netdevs. If they have special

> No, implementation wise I'd avoid changing the class on the fly. What > I'm looking to is a means to add a secondary class or class aliasing > mechanism for netdevs that allows mapping for a kernel device > namespace (/class/net-kernel) to userspace (/class/net). Imagine > creating symlinks between these two namespaces as an analogy. All > userspace visible netdevs