| Message ID | 1404980258-30853-16-git-send-email-teg@jklm.no |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
On 07/10/2014 01:47 PM, Tom Gundersen wrote: > The name contains then xen handle, which is not guaranteed to be > stable between restarts, so label this NET_NAME_ENUM. > > Signed-off-by: Tom Gundersen <teg@jklm.no> > Cc: Ian Campbell <ian.campbell@citrix.com> > Cc: Wei Liu <wei.liu2@citrix.com> > Cc: xen-devel@lists.xenproject.org > --- > drivers/net/xen-netback/interface.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c > index 793275d..da906d1 100644 > --- a/drivers/net/xen-netback/interface.c > +++ b/drivers/net/xen-netback/interface.c > @@ -418,8 +418,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid, > * When the guest selects the desired number, it will be updated > * via netif_set_real_num_*_queues(). > */ > - dev = alloc_netdev_mq(sizeof(struct xenvif), name, NET_NAME_UNKNOWN, > - ether_setup, xenvif_max_queues); > + dev = alloc_netdev_mq(sizeof(struct xenvif), name, NET_NAME_ENUM, ether_setup, > + xenvif_max_queues); What i am suggesting is irrelavent to this patch. But also consider this suggestion In place sizeof(struct xenvif) --> sizeof(*vif) ??? > if (dev == NULL) { > pr_warn("Could not allocate netdev for %s\n", name); > return ERR_PTR(-ENOMEM);
On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote: > The name contains then xen handle, which is not guaranteed to be > stable between restarts, so label this NET_NAME_ENUM. FWIW the N'th interface for domain with domid D will always be named vifD.N. If you reboot domain D then it's domid will change to E and the new device will be vifE.N. I don't know if that counts as predictable as far as the interface you are introducing is concerned. Ian. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 10, 2014 at 11:01 AM, Ian Campbell <ian.campbell@citrix.com> wrote: > On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote: >> The name contains then xen handle, which is not guaranteed to be >> stable between restarts, so label this NET_NAME_ENUM. > > FWIW the N'th interface for domain with domid D will always be named > vifD.N. > > If you reboot domain D then it's domid will change to E and the new > device will be vifE.N. > > I don't know if that counts as predictable as far as the interface you > are introducing is concerned. That was my understanding, thanks for confirming. The idea is that the same interface on the same machine must get the same name between reboots in order to be considered predictable. So under the assumption that a rebooted domain should be considered "the same machine" (i.e., it still has the same local configuration, possibly referencing the interface names), then we should consider the names not predictable, so NET_NAME_ENUM. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2014-07-10 at 12:46 +0200, Tom Gundersen wrote: > On Thu, Jul 10, 2014 at 11:01 AM, Ian Campbell <ian.campbell@citrix.com> wrote: > > On Thu, 2014-07-10 at 10:17 +0200, Tom Gundersen wrote: > >> The name contains then xen handle, which is not guaranteed to be > >> stable between restarts, so label this NET_NAME_ENUM. > > > > FWIW the N'th interface for domain with domid D will always be named > > vifD.N. > > > > If you reboot domain D then it's domid will change to E and the new > > device will be vifE.N. > > > > I don't know if that counts as predictable as far as the interface you > > are introducing is concerned. > > That was my understanding, thanks for confirming. > > The idea is that the same interface on the same machine must get the > same name between reboots in order to be considered predictable. So > under the assumption that a rebooted domain should be considered "the > same machine" (i.e., it still has the same local configuration, > possibly referencing the interface names), then we should consider the > names not predictable, so NET_NAME_ENUM. OK, thanks. I'll defer to you understanding of what this interface is supposed to mean: Acked-by: Ian Campbell <ian.campbell@citrix.com> Ian. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c index 793275d..da906d1 100644 --- a/drivers/net/xen-netback/interface.c +++ b/drivers/net/xen-netback/interface.c @@ -418,8 +418,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid, * When the guest selects the desired number, it will be updated * via netif_set_real_num_*_queues(). */ - dev = alloc_netdev_mq(sizeof(struct xenvif), name, NET_NAME_UNKNOWN, - ether_setup, xenvif_max_queues); + dev = alloc_netdev_mq(sizeof(struct xenvif), name, NET_NAME_ENUM, ether_setup, + xenvif_max_queues); if (dev == NULL) { pr_warn("Could not allocate netdev for %s\n", name); return ERR_PTR(-ENOMEM);
The name contains then xen handle, which is not guaranteed to be stable between restarts, so label this NET_NAME_ENUM. Signed-off-by: Tom Gundersen <teg@jklm.no> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Wei Liu <wei.liu2@citrix.com> Cc: xen-devel@lists.xenproject.org --- drivers/net/xen-netback/interface.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)