From: Casey Leedom <leedom@chelsio.com>
To: Stefan Assmann <sassmann@redhat.com>
Cc: e1000-devel@lists.sourceforge.net,
netdev <netdev@vger.kernel.org>,
gregory.v.rose@intel.com, jeffrey.t.kirsher@intel.com,
Andy Gospodarek <gospo@redhat.com>
Subject: Re: [PATCH] igbvf: avoid name clash between PF and VF
Date: Thu, 1 Jul 2010 10:12:47 -0700 [thread overview]
Message-ID: <201007011012.48236.leedom@chelsio.com> (raw)
In-Reply-To: <4C2C378D.4090806@redhat.com>
| From: Stefan Assmann <sassmann@redhat.com>
| Date: Wednesday, June 30, 2010 11:37 pm
|
| You're correct, the problem shouldn't occur with cxgb4vf and therefore
| this change shouldn't be necessary. However we might consider a
| consistent naming scheme for VFs in all drivers. But I don't have a
| strong opinion about this, either way would be fine by me.
Sorry, I hadn't meant to imply any criticism of your naming proposal. I was
just trying to clarify when/where such a scheme might be necessary.
On the naming proposal itself, it strikes me that the most common use of PCI-E
SR-IOV Virtual Functions will be to export them to KVM Virtual Machines via PCI
"Pass Through." So there shouldn't be any naming conflict there, right? Or is
it the same scenario you described before: that the VF NIC device might be found
before the normal "eth0", etc. withing the Virtual Machine?
In any case, I don't really have any feelings one way or the other about
interface naming. As I mentioned before, the cxgb4vf driver will end up with
persistent MAC addresses so all the normal interface management stuff will work
normally (naming, DHCP, etc.)
Casey
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
next prev parent reply other threads:[~2010-07-01 17:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-30 8:53 [PATCH] igbvf: avoid name clash between PF and VF Stefan Assmann
2010-06-30 10:44 ` Ben Hutchings
2010-06-30 10:57 ` Stefan Assmann
2010-06-30 11:11 ` Kay Sievers
2010-06-30 13:07 ` Harald Hoyer
2010-06-30 16:59 ` Casey Leedom
2010-07-01 6:37 ` Stefan Assmann
2010-07-01 17:12 ` Casey Leedom [this message]
2010-07-02 6:37 ` Stefan Assmann
2010-07-08 13:41 ` Arnd Bergmann
2010-07-09 9:31 ` Stefan Assmann
2010-07-09 15:33 ` Rose, Gregory V
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007011012.48236.leedom@chelsio.com \
--to=leedom@chelsio.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=gospo@redhat.com \
--cc=gregory.v.rose@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=sassmann@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.