On Wed, Apr 18, 2018 at 11:10 PM, Samudrala, Sridhar
wrote:
>
> On 4/18/2018 10:07 PM, Michael S. Tsirkin wrote:
>>
>> On Wed, Apr 18, 2018 at 10:00:51PM -0700, Samudrala, Sridhar wrote:
>>>
>>> On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote:
On Wed, Apr 18, 2018 at 04:33:34PM -0700, Sam
On Wed, Apr 18, 2018 at 10:00 PM, Samudrala, Sridhar
wrote:
> On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote:
>>
>> On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote:
>>>
>>> On 4/17/2018 5:26 PM, Siwei Liu wrote:
I ran this with a few folks offline and gathered some goo
On 4/18/2018 10:07 PM, Michael S. Tsirkin wrote:
On Wed, Apr 18, 2018 at 10:00:51PM -0700, Samudrala, Sridhar wrote:
On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote:
On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote:
On 4/17/2018 5:26 PM, Siwei Liu wrote:
I ran this with a fe
On Wed, Apr 18, 2018 at 10:00:51PM -0700, Samudrala, Sridhar wrote:
> On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote:
> > On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote:
> > > On 4/17/2018 5:26 PM, Siwei Liu wrote:
> > > > I ran this with a few folks offline and gathered some go
On 4/18/2018 9:41 PM, Michael S. Tsirkin wrote:
On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote:
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 il
On Wed, Apr 18, 2018 at 04:33:34PM -0700, Samudrala, Sridhar wrote:
> 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, clou
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
targe
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 m
On Sun, Apr 8, 2018 at 9:32 AM, David Miller wrote:
> From: Siwei Liu
> 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'
On Mon, Apr 9, 2018 at 4:03 PM, Stephen Hemminger
wrote:
> On Mon, 9 Apr 2018 15:30:42 -0700
> Siwei Liu wrote:
>
>> On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn 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 c
On Mon, 9 Apr 2018 15:30:42 -0700
Siwei Liu wrote:
> On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn 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 mapp
On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn 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 u
> 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 betwe
On Fri, Apr 6, 2018 at 8:19 PM, Andrew Lunn wrote:
> Hi Siwei
>
>> I think everyone seems to agree not to fiddle with the ":" prefix, but
>> rather have a new class of network subsystem under /sys/class thus a
>> separate device namespace e.g. /sys/class/net-kernel for those
>> auto-managed lower
From: Siwei Liu
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 cl
Hi Siwei
> I think everyone seems to agree not to fiddle with the ":" prefix, but
> rather have a new class of network subsystem under /sys/class thus a
> separate device namespace e.g. /sys/class/net-kernel for those
> auto-managed lower netdevs is needed.
How do you get a device into this new
On Wed, Apr 4, 2018 at 10:37 AM, David Miller wrote:
> From: David Ahern
> 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 in
(put discussions back on list which got accidentally removed)
On Tue, Apr 3, 2018 at 4:08 PM, Stephen Hemminger
wrote:
> On Tue, 3 Apr 2018 12:04:38 -0700
> Siwei Liu wrote:
>
>> On Tue, Apr 3, 2018 at 10:35 AM, Stephen Hemminger
>> wrote:
>> > On Sun, 1 Apr 2018 05:13:09 -0400
>> > Si-Wei Liu
> 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 contri
Wed, Apr 04, 2018 at 07:37:49PM CEST, da...@davemloft.net wrote:
>From: David Ahern
>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 st
On Wed, Apr 4, 2018 at 10:21 AM, David Ahern wrote:
> On 4/4/18 1:36 AM, Siwei Liu wrote:
>> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern 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 yo
On Wed, 4 Apr 2018 11:37:52 -0600
David Ahern 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.
From: David Ahern
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
[ dropping virtio-...@lists.oasis-open.org since it is a closed list and
I am tired of deleting bounces ]
On 4/4/18 2:28 AM, Siwei Liu wrote:
> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern wrote:
>> On 4/3/18 9:42 AM, Jiri Pirko wrote:
There are other use cases that want to hide a device
From: David Ahern
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
On 4/4/18 1:36 AM, Siwei Liu wrote:
> On Tue, Apr 3, 2018 at 6:04 PM, David Ahern 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 som
On Tue, Apr 3, 2018 at 6:04 PM, David Ahern 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. Ju
On Tue, Apr 3, 2018 at 11:19 PM, Jiri Pirko wrote:
> Wed, Apr 04, 2018 at 03:04:26AM CEST, dsah...@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 i
On Tue, Apr 3, 2018 at 6:04 PM, David Ahern 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. Ju
Wed, Apr 04, 2018 at 03:04:26AM CEST, dsah...@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
>ne
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 with it, and
S/
On Tue, Apr 3, 2018 at 8:42 AM, Jiri Pirko wrote:
> Sun, Apr 01, 2018 at 06:11:29PM CEST, dsah...@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 existe
On Sun, 1 Apr 2018 05:13:09 -0400
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
Sun, Apr 01, 2018 at 06:11:29PM CEST, dsah...@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 asso
On 4/3/18 1:40 AM, Siwei Liu wrote:
>> There are other use cases that want to hide a device from userspace.
>
> Can you elaborate your case in more details? Looking at the links
> below I realize that the purpose of hiding devices in your case is
> quite different from the our migration case. Part
On Sun, Apr 1, 2018 at 9:11 AM, David Ahern 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 wit
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. Alt
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
manipulate the lower net
38 matches
Mail list logo
