netdev - Re: [net-next-2.6 PATCH 2/2] add ndo_set_port_profile op support for enic dynamic vnics

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: <alpine.LFD.2.00.1005022119140.16925@vk>
Date:	Sun, 2 May 2010 21:29:10 -0700 (PDT)
From:	Vivek Kashyap <kashyapv@...ibm.com>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Scott Feldman <scofeldm@...co.com>, davem@...emloft.net,
	netdev@...r.kernel.org, chrisw@...hat.com,
	Jens Osterkamp <Jens.Osterkamp@....de>
Subject: Re: [net-next-2.6 PATCH 2/2] add ndo_set_port_profile op support
 for enic dynamic vnics

>
>>>>    ip port_profile set DEVICE [ base DEVICE ] [ { pre_associate |
>>>>                                                   pre_associate_rr } ]
>>>>                               { name PORT-PROFILE | vsi MGR:VTID:VER }
>>
>> BTW, I was meaning to ask: is there a way to role the vsi tuple and the
>> flags up into a single identifier, say a string like PORT-PROFILE?  I'm
>> asking because it seems awkward from an admin's perspective to know how to
>> construct a vsi tuple or to know what pre_associate_rr means. I have to
>> admit I didn't fully grok what pre_associate_rr means myself.  Even if there
>> was a simple local database to map named port-profiles to the underlying
>> {vsi tuple, flags}, that would bring us closer to a more consistent user
>> interface.  Is this possible?
>
> I think that's technically possible but may not be helpful to make the
> user interface easier. Some background on pre-associate:
>
> The purpose of this is to assist guest migration. A single VSI (i.e. guest
> network adapter) may only be connected to a single switch port at any
> given time. The VSI is identified by its UUID and it has a unique
> MAC address.
>
> When migrating a guest to a new hypervisor, we need to ask the switch
> to associate that VSI at the destination switch port (which may or may
> not be on the same different switch as the source port). This operation
> may fail for a number of reasons and can take some time. Since we want
> migration to alway succeed and take as little time as possible, we
> do a pre-associate-with-resource-reservation before the migration and
> only start the actual guest migration if that completes successfully.
>
> After a successful pre-associate-with-resource-reservation step, we
> know that the actual associate step will be both fast and successful.
> After it completes, the VSI is known to be on the destination
> and all traffic goes there (replacing the gratuitous ARP method we do
> today).
>
> I don't think we'd ever do a pre-associate without the
> resource-reservation, but the standard defines both. In theory,
> we could do a pre-associate at every switch in the data center
> in order to find out if it's possible to migrate there.
>
> If you want to have more details, please look at the draft spec at
> http://www.ieee802.org/1/files/public/docs2010/bg-joint-evb-0410v1.pdf

The basic difference is that in 'pre-associate with resoruce reservation', the 
local buffers and resources needed for the eventual 'associate' are reserved
at the switch port.  Therefore the associate will not fail with 
'insufficient resources'. It might otherwise.

thanks
 	Vivek

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