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

Displaying 20 results from an estimated 2000 matches similar to: "[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice"

2018 Apr 04
0
[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 >>>>
2018 Apr 04
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 04
1
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 04
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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.
2018 Apr 04
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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.
2018 Apr 03
1
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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.
2018 Apr 03
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 04
4
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 04
4
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 07
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 04
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
> 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
2018 Apr 06
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
(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
2018 Apr 09
1
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 10
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 18
0
[virtio-dev] Re: [RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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 >
2018 Apr 09
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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 >>
2018 Apr 03
0
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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 >
2018 Apr 08
2
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 08
2
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
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
2018 Apr 09
2
[RFC PATCH 2/3] netdev: kernel-only IFF_HIDDEN netdevice
> 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