netdev - Re: [PATCH] virtif: initial interface extensions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <loom.20100511T015142-35@post.gmane.org>
Date:	Mon, 10 May 2010 23:51:57 +0000 (UTC)
From:	Stefan Berger <stefanb@...ibm.com>
To:	netdev@...r.kernel.org
Subject: Re: [PATCH] virtif: initial interface extensions

Arnd Bergmann <arnd@...db.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 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html