All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@us.ibm.com>
To: netdev@vger.kernel.org
Subject: Re: [PATCH] virtif: initial interface extensions
Date: Mon, 10 May 2010 23:51:57 +0000 (UTC)	[thread overview]
Message-ID: <loom.20100511T015142-35@post.gmane.org> (raw)
In-Reply-To: 201005102346.38229.arnd@arndb.de

Arnd Bergmann <arnd@arndb.de> wrote on 05/10/2010 05:46:37 PM:


> The other question is which protocol we're using. There are as far as I
> can tell five options:
> 
> 1. enic device driver
> 2. VDP
> 3. CDCP
> 4. CDCP + VDP
> 5. enic + VDP
> 
> The first two ones are the most interesting for now, since Linux cannot do
> S-VLANs yet, and they are required for CDCP. However, each of these options
> could theoreticall be done in the kernel (plus firmware) or in user space.
> 
> If it's done in user space, the VF number is meaningless, because the setup
> of the software device is also done from software, but instead you need to
> take care of creating the software device with the correct parameters, e.g.
> a macvtap device connected to a VLAN interface using the numbers you pass
> in the VDP protocol.
> 
> Right now, we're not planning to do the protocol that enic uses in LLDPAD,
> because it's not publically released. Similarly, there are no adapters that
> do VDP in firmware, but both these cases should be covered by the protocol
> and it would be good if libvirt could handle them.
> 
> 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? 

> 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. 

>   2.2. enic
>      2.2.1 port profile name 

as proposed on libvirt mailing list 

>      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? 


>   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. 


    Stefan 


  reply	other threads:[~2010-05-10 23:52 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 [this message]
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
     [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=loom.20100511T015142-35@post.gmane.org \
    --to=stefanb@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    /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.