[dpdk-dev] [PATCH 1/2] vhost: enable any layout feature

[Michael S. Tsirkin]

On Tue, Sep 27, 2016 at 11:11:58AM +0800, Yuanhan Liu wrote:
> On Mon, Sep 26, 2016 at 10:24:55PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Sep 26, 2016 at 11:01:58AM -0700, Stephen Hemminger wrote:
> > > I assume that if using Version 1 that the bit will be ignored
> 
> Yes, but I will just quote what you just said: what if the guest
> virtio device is a legacy device? I also gave my reasons in another
> email why I consistently set this flag:
> 
>   - we have to return all features we support to the guest.
>   
>     We don't know the guest is a modern or legacy device. That means
>     we should claim we support both: VERSION_1 and ANY_LAYOUT.
>   
>     Assume guest is a legacy device and we just set VERSION_1 (the current
>     case), ANY_LAYOUT will never be negotiated.
>   
>   - I'm following the way Linux kernel takes: it also set both features.
>   
>   Maybe, we could unset ANY_LAYOUT when VERSION_1 is _negotiated_?
> 
> The unset after negotiation I proposed turned out it won't work: the
> feature is already negotiated; unsetting it only in vhost side doesn't
> change anything. Besides, it may break the migration as Michael stated
> below.

I think the reverse. Teach vhost user that for future machine types
only VERSION_1 implies ANY_LAYOUT.


> > Therein lies a problem. If dpdk tweaks flags, updating it
> > will break guest migration.
> > 
> > One way is to require that users specify all flags fully when
> > creating the virtio net device. 
> 
> Like how? By a new command line option? And user has to type
> all those features?

Make libvirt do this.  users use management normally. those that don't
likely don't migrate VMs.

> > QEMU could verify that all required
> > flags are set, and fail init if not.
> > 
> > This has other advantages, e.g. it adds ability to
> > init device without waiting for dpdk to connect.
> > 
> > However, enabling each new feature would now require
> > management work. How about dpdk ships the list
> > of supported features instead?
> > Management tools could read them on source and destination
> > and select features supported on both sides.
> 
> That means the management tool would somehow has a dependency on
> DPDK project, which I have no objection at all. But, is that
> a good idea?

It already starts the bridge somehow, does it not?

> BTW, I'm not quite sure I followed your idea. I mean, how it supposed
> to fix the ANY_LAYOUT issue here? How this flag will be set for
> legacy device?
> 
> 	--yliu

For ANY_LAYOUT, I think we should just set in in qemu,
but only for new machine types. This addresses migration
concerns.

But there will be more new features in the future and
it is necessary to think how we will enable them without
breaking migration.

-- 
MST