On Wed, 24 Jan 2018 11:53:11 +0100, Nicolas Dichtel wrote:
> Le 23/01/2018 à 18:08, Jiri Benc a écrit :
> > It would be much better if the whole (ifindex, netnsid) pair was
> > returned. I think it could be added.
> Sure. Do you plan to send a patch?
I can do that but it will take a while. I'll
On Wed, 24 Jan 2018 11:53:11 +0100, Nicolas Dichtel wrote:
> Le 23/01/2018 à 18:08, Jiri Benc a écrit :
> > It would be much better if the whole (ifindex, netnsid) pair was
> > returned. I think it could be added.
> Sure. Do you plan to send a patch?
I can do that but it will take a while. I'll
Le 23/01/2018 à 18:08, Jiri Benc a écrit :
> On Tue, 23 Jan 2018 17:37:11 +0100, Nicolas Dichtel wrote:
>> When a virtual interface moves to another netns, the netlink RTM_DELLINK
>> message
>> contains the attribute IFLA_NEW_NETNSID, which identifies where the interface
>> moves. The nsid may be
Le 23/01/2018 à 18:08, Jiri Benc a écrit :
> On Tue, 23 Jan 2018 17:37:11 +0100, Nicolas Dichtel wrote:
>> When a virtual interface moves to another netns, the netlink RTM_DELLINK
>> message
>> contains the attribute IFLA_NEW_NETNSID, which identifies where the interface
>> moves. The nsid may be
On Tue, 23 Jan 2018 17:37:11 +0100, Nicolas Dichtel wrote:
> When a virtual interface moves to another netns, the netlink RTM_DELLINK
> message
> contains the attribute IFLA_NEW_NETNSID, which identifies where the interface
> moves. The nsid may be allocated if needed.
The problem is that
On Tue, 23 Jan 2018 17:37:11 +0100, Nicolas Dichtel wrote:
> When a virtual interface moves to another netns, the netlink RTM_DELLINK
> message
> contains the attribute IFLA_NEW_NETNSID, which identifies where the interface
> moves. The nsid may be allocated if needed.
The problem is that
Le 23/01/2018 à 11:26, Wolfgang Bumiller a écrit :
> On Tue, Jan 23, 2018 at 10:30:09AM +0100, Jiri Benc wrote:
>> On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
>>> This is not necessarily true in scenarios where I move a network device
>>> via RTM_NEWLINK + IFLA_NET_NS_PID into a
Le 23/01/2018 à 11:26, Wolfgang Bumiller a écrit :
> On Tue, Jan 23, 2018 at 10:30:09AM +0100, Jiri Benc wrote:
>> On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
>>> This is not necessarily true in scenarios where I move a network device
>>> via RTM_NEWLINK + IFLA_NET_NS_PID into a
Le 22/01/2018 à 23:06, Jiri Benc a écrit :
[snip]
> Btw, we have one missing piece here: when an interface is moved to a
> name space that does not have netnsid attached, we want to find out
> where the interface was moved to. But there's currently no reliable way
> to do it. For veth, the other
Le 22/01/2018 à 23:06, Jiri Benc a écrit :
[snip]
> Btw, we have one missing piece here: when an interface is moved to a
> name space that does not have netnsid attached, we want to find out
> where the interface was moved to. But there's currently no reliable way
> to do it. For veth, the other
On Tue, 23 Jan 2018 11:26:58 +0100, Wolfgang Bumiller wrote:
> Even if you know the netnsid, do the mentioned watches work for
> nested/child namespaces if eg. a container creates new namespace before
> and/or after the watch was established and moves interfaces to these
> child namespaces, would
On Tue, 23 Jan 2018 11:26:58 +0100, Wolfgang Bumiller wrote:
> Even if you know the netnsid, do the mentioned watches work for
> nested/child namespaces if eg. a container creates new namespace before
> and/or after the watch was established and moves interfaces to these
> child namespaces, would
On Tue, Jan 23, 2018 at 10:30:09AM +0100, Jiri Benc wrote:
> On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> > This is not necessarily true in scenarios where I move a network device
> > via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't
> > created. Here is an
On Tue, Jan 23, 2018 at 10:30:09AM +0100, Jiri Benc wrote:
> On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> > This is not necessarily true in scenarios where I move a network device
> > via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't
> > created. Here is an
On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> This is not necessarily true in scenarios where I move a network device
> via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't
> created. Here is an example:
>
> nlmsghdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>
On Mon, 22 Jan 2018 23:25:41 +0100, Christian Brauner wrote:
> This is not necessarily true in scenarios where I move a network device
> via RTM_NEWLINK + IFLA_NET_NS_PID into a network namespace I haven't
> created. Here is an example:
>
> nlmsghdr->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
>
On Mon, Jan 22, 2018 at 11:06:16PM +0100, Jiri Benc wrote:
> On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote:
> > That is certainly a good idea and I'm happy to send a follow-up patch
> > for that!
>
> Note that I haven't looked into that and I don't know whether it is
> easily
On Mon, Jan 22, 2018 at 11:06:16PM +0100, Jiri Benc wrote:
> On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote:
> > That is certainly a good idea and I'm happy to send a follow-up patch
> > for that!
>
> Note that I haven't looked into that and I don't know whether it is
> easily
On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote:
> That is certainly a good idea and I'm happy to send a follow-up patch
> for that!
Note that I haven't looked into that and I don't know whether it is
easily possible. I'll appreciate if you could try that.
> But there's still value
On Mon, 22 Jan 2018 22:23:54 +0100, Christian Brauner wrote:
> That is certainly a good idea and I'm happy to send a follow-up patch
> for that!
Note that I haven't looked into that and I don't know whether it is
easily possible. I'll appreciate if you could try that.
> But there's still value
On Mon, Jan 22, 2018 at 10:00:46PM +0100, Jiri Benc wrote:
> On Thu, 18 Jan 2018 21:55:53 +0100, Christian Brauner wrote:
> > A more concrete scenario is creating a network namespace, moving a
> > device into it via RTM_SETLINK which also supports IFLA_NET_NS_{FD,PID}
> > and then wanting to query
On Mon, Jan 22, 2018 at 10:00:46PM +0100, Jiri Benc wrote:
> On Thu, 18 Jan 2018 21:55:53 +0100, Christian Brauner wrote:
> > A more concrete scenario is creating a network namespace, moving a
> > device into it via RTM_SETLINK which also supports IFLA_NET_NS_{FD,PID}
> > and then wanting to query
On Thu, 18 Jan 2018 21:55:53 +0100, Christian Brauner wrote:
> A more concrete scenario is creating a network namespace, moving a
> device into it via RTM_SETLINK which also supports IFLA_NET_NS_{FD,PID}
> and then wanting to query the device. This would be very easy to do if
> one could reuse the
On Thu, 18 Jan 2018 21:55:53 +0100, Christian Brauner wrote:
> A more concrete scenario is creating a network namespace, moving a
> device into it via RTM_SETLINK which also supports IFLA_NET_NS_{FD,PID}
> and then wanting to query the device. This would be very easy to do if
> one could reuse the
On Thu, Jan 18, 2018 at 09:29:14PM +0100, Jiri Benc wrote:
> On Thu, 18 Jan 2018 21:21:24 +0100, Christian Brauner wrote:
> > In such scenarios setting a netns id property is
> > not really wanted
>
> Why? I think that's what you should do if you want to avoid setns. Just
> use netnsid. I don't
On Thu, Jan 18, 2018 at 09:29:14PM +0100, Jiri Benc wrote:
> On Thu, 18 Jan 2018 21:21:24 +0100, Christian Brauner wrote:
> > In such scenarios setting a netns id property is
> > not really wanted
>
> Why? I think that's what you should do if you want to avoid setns. Just
> use netnsid. I don't
On Thu, 18 Jan 2018 21:21:24 +0100, Christian Brauner wrote:
> In such scenarios setting a netns id property is
> not really wanted
Why? I think that's what you should do if you want to avoid setns. Just
use netnsid. I don't see any problem with that and you didn't provide
any explanation.
Jiri
On Thu, 18 Jan 2018 21:21:24 +0100, Christian Brauner wrote:
> In such scenarios setting a netns id property is
> not really wanted
Why? I think that's what you should do if you want to avoid setns. Just
use netnsid. I don't see any problem with that and you didn't provide
any explanation.
Jiri
This makes it possible to identify the target network namespace of a
RTM_GETLINK message by pid or fd.
Often userspace tools that make heavy use of network namespaces need a
simple and cheap way of querying network devices and network device
properties. This becomes even more crucial when the
This makes it possible to identify the target network namespace of a
RTM_GETLINK message by pid or fd.
Often userspace tools that make heavy use of network namespaces need a
simple and cheap way of querying network devices and network device
properties. This becomes even more crucial when the
30 matches
Mail list logo
