From: Arnd Bergmann <arnd@arndb.de>
To: Stefan Berger <stefanb@us.ibm.com>
Cc: netdev@vger.kernel.org, Scott Feldman <scofeldm@cisco.com>
Subject: Re: [PATCH] virtif: initial interface extensions
Date: Tue, 11 May 2010 14:25:27 +0200 [thread overview]
Message-ID: <201005111425.27366.arnd@arndb.de> (raw)
In-Reply-To: <OFFE8F5F70.5C07C656-ON8525771F.00787A71-8525771F.007FCDFC@us.ibm.com>
On Tuesday 11 May 2010, Stefan Berger wrote:
> Arnd Bergmann <arnd@arndb.de> wrote on 05/10/2010 05:46:37 PM:
>
> > Stefan, can you just define the XML in a way that matches the netlink
> > definition? What you need is something like
> >
> > 1. VF number (optional, signifies that 2/3 are done in firmware)
>
> Shouldn't we be able to query that number via netlink starting with the
> macvtap device and the following the trail to the root and trying to find
> a VF number on the way?
No. If we have a macvtap device, there is no VF number. The VF number
should be known to libvirt in those cases where instead of creating a
macvtap device, it assigns a VF of an SR-IOV adapter to the guest.
> > 2. Lower-level protocol
> > 2.1. CDCP
> > 2.1.1 SVID
> > 2.1.2 SCID
>
> Will the later on be qeueryable via netlink as well but not today???
> Vivek tells me svid is vlan, so that could be found out from the kernel.
>
> So if we want to only support 1 and 2 for now, I'd rather skip them for
> now.
svid is almost vlan (hence S-VLAN), but slightly different and is not
currently supported by the kernel. Again, if the implementation is done in
firmware, libvirt needs to set the same S-VLAN ID when setting up the
VF and when associating it to the switch.
When it's done in software, we need to create the device (or have
it created in advance), so you either know it or can query it as
you describe.
You don't need to support it yet in libvirt, but the definition should
be done in a way that leaves the option open to add it later.
> > 2.2.2 ...
> > 3. VDP
> > 3.1 VSI type/version/provider
>
> as proposed on libvirt mailing list
>
> > 3.2 UUID
>
> we have a couple of UUIDs, which one?
This is a UUID that describes the VSI to the switch. It needs to be
unique in the migration domain. For a guest that has multiple
macvtap interfaces, you either need to have a single UUID and
put all MAC/VLAN pairs into the same netlink message with this
UUID, or have one UUID per device.
> > 3.3 MAC/VLAN
>
> MAC: available from libvirt
> VLAN: can be found out by querying for every interface for VLAN ID while
> following the path towards the root device.
Yes, in case of macvtap.
Arnd
next prev parent reply other threads:[~2010-05-11 12:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 4:42 [net-next-2.6 V5 PATCH 0/3] Add port-profile netlink support Scott Feldman
2010-05-06 4:42 ` [net-next-2.6 V5 PATCH 1/3] Add netdev/netlink port-profile support (was iovnl) Scott Feldman
2010-05-06 4:42 ` [net-next-2.6 V5 PATCH 2/3] Add ndo_{set|get}_vf_port_profile op support for enic dynamic vnics Scott Feldman
2010-05-06 13:47 ` Arnd Bergmann
2010-05-06 16:25 ` Scott Feldman
2010-05-06 16:45 ` Arnd Bergmann
2010-05-06 4:42 ` [net-next-2.6 V5 PATCH 3/3] Add SR-IOV support to enic (please don't apply this patch) Scott Feldman
2010-05-06 13:51 ` [net-next-2.6 V5 PATCH 0/3] Add port-profile netlink support Arnd Bergmann
2010-05-06 16:19 ` Scott Feldman
2010-05-06 16:42 ` Arnd Bergmann
2010-05-08 23:20 ` [PATCH] virtif: initial interface extensions Arnd Bergmann
2010-05-10 15:37 ` Stefan Berger
2010-05-10 18:56 ` Scott Feldman
2010-05-10 21:46 ` Arnd Bergmann
2010-05-10 23:51 ` Stefan Berger
2010-05-11 0:25 ` Scott Feldman
2010-05-11 12:59 ` Arnd Bergmann
2010-05-11 17:15 ` Vivek Kashyap
[not found] ` <OFFE8F5F70.5C07C656-ON8525771F.00787A71-8525771F.007FCDFC@us.ibm.com>
2010-05-11 12:25 ` Arnd Bergmann [this message]
[not found] ` <OF2E2B37D4.51A81D74-ON85257720.0045FA96-85257720.004C5403@us.ibm.com>
2010-05-11 14:22 ` Arnd Bergmann
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=201005111425.27366.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=netdev@vger.kernel.org \
--cc=scofeldm@cisco.com \
--cc=stefanb@us.ibm.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.