OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature


On Tue, Sep 18, 2018 at 12:20:52PM +0200, Cornelia Huck wrote:
> On Wed, 12 Sep 2018 11:22:12 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Wed, Sep 12, 2018 at 08:17:45AM -0700, Samudrala, Sridhar wrote:
> > > 
> > > 
> > > On 9/7/2018 2:34 PM, Michael S. Tsirkin wrote:  
> > > > On Wed, Aug 15, 2018 at 11:49:15AM -0700, Sridhar Samudrala wrote:  
> > > > > VIRTIO_NET_F_STANDBY feature enables hypervisor to indicate virtio_net
> > > > > device to act as a standby for another device with the same MAC address.
> > > > > 
> > > > > Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > > > > Acked-by: Cornelia Huck <cohuck@redhat.com>
> > > > > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/18  
> > > > Applied but when do you plan to add documentation as pointed
> > > > out by Jan and Halil?  
> > > 
> > > I thought additional documentation will be done as part of the Qemu enablement
> > > patches and i hope someone in RH is looking into it.
> > > 
> > > Does it make sense to add a link to to the kernel documentation of this feature in
> > > the spec
> > >  https://www.kernel.org/doc/html/latest/networking/net_failover.html  
> > 
> > 
> > I do not think this will address the comments posted.  Specifically we
> > should probably include documentation for what is a standby and primary:
> > what is expected of driver (maintain configuration on standby, support
> > primary coming and going, transmit on standby only if there is no
> > primary) and of device (have same mac for standby as for standby).
> 
> Yes, we need some definitive statements of what a driver and a device
> is supposed to do in order to conform; it might make sense to discuss
> this in conjunction with discussion on any QEMU patches (have not
> checked whether anything has been posted, just returned from vacation).
> 
> I assume that we still stick with the plan to implement/document
> MAC-based handling first and then enhance with other methods later?

I'm fine with that at least. If someone wants to work on
other methods straight away, that's also fine by me.

-- 
MST


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]