> -----Original Message-----
> From: Kavanagh, Mark B
> Sent: Friday, November 24, 2017 4:45 PM
> To: Jan Scheurich <jan.scheur...@ericsson.com>; Kevin Traynor
> <ktray...@redhat.com>; d...@openvswitch.org
> Cc: maxime.coque...@redhat.com; Flavio Leitner <f...@redhat.com>; Franck
> Baudin <fbau...@redhat.com>; Mooney, Sean K <sean.k.moo...@intel.com>;
> Ilya Maximets <i.maxim...@samsung.com>; Stokes, Ian
> <ian.sto...@intel.com>; Loftus, Ciara <ciara.lof...@intel.com>; Darrell
> Ball <db...@vmware.com>; Aaron Conole <acon...@redhat.com>
> Subject: RE: [ovs-dev] [PATCH 2/2] netdev-dpdk: add support for vhost
> IOMMU feature
>
> Sounds good guys - I'll get cracking on this on Monday.
>
> Cheers,
> Mark
>
> >-----Original Message-----
> >From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> >Sent: Friday, November 24, 2017 4:21 PM
> >To: Kevin Traynor <ktray...@redhat.com>; Kavanagh, Mark B
> ><mark.b.kavan...@intel.com>; d...@openvswitch.org
> >Cc: maxime.coque...@redhat.com; Flavio Leitner <f...@redhat.com>;
> Franck
> >Baudin <fbau...@redhat.com>; Mooney, Sean K <sean.k.moo...@intel.com>;
> >Ilya Maximets <i.maxim...@samsung.com>; Stokes, Ian
> ><ian.sto...@intel.com>; Loftus, Ciara <ciara.lof...@intel.com>;
> Darrell
> >Ball <db...@vmware.com>; Aaron Conole <acon...@redhat.com>
> >Subject: RE: [ovs-dev] [PATCH 2/2] netdev-dpdk: add support for vhost
> >IOMMU feature
> >
> >+1
> >Jan
> >
> >> -----Original Message-----
> >> From: Kevin Traynor [mailto:ktray...@redhat.com]
> >> Sent: Friday, 24 November, 2017 17:11
> >> To: Mark Kavanagh <mark.b.kavan...@intel.com>; d...@openvswitch.org
> >> Cc: maxime.coque...@redhat.com; Flavio Leitner <f...@redhat.com>;
> >> Franck
> >Baudin <fbau...@redhat.com>; Mooney, Sean K
> >> <sean.k.moo...@intel.com>; Ilya Maximets <i.maxim...@samsung.com>;
> >> Ian
> >Stokes <ian.sto...@intel.com>; Loftus, Ciara
> >> <ciara.lof...@intel.com>; Darrell Ball <db...@vmware.com>; Aaron
> >> Conole
> ><acon...@redhat.com>; Jan Scheurich
> >> <jan.scheur...@ericsson.com>
> >> Subject: Re: [ovs-dev] [PATCH 2/2] netdev-dpdk: add support for
> vhost
> >> IOMMU
> >feature
> >>
> >> On 11/16/2017 11:01 AM, Mark Kavanagh wrote:
> >> > DPDK v17.11 introduces support for the vHost IOMMU feature.
> >> > This is a security feature, that restricts the vhost memory that a
> >> > virtio device may access.
> >> >
> >> > This feature also enables the vhost REPLY_ACK protocol, the
> >> > implementation of which is known to work in newer versions of QEMU
> >> > (i.e. v2.10.0), but is buggy in older versions (v2.7.0 - v2.9.0,
> >> > inclusive). As such, the feature is disabled by default in (and
> >> > should remain so, for the aforementioned older QEMU verions).
> >> > Starting with QEMU v2.9.1, vhost-iommu-support can safely be
> >> > enabled, even without having an IOMMU device, with no performance
> >> > penalty.
> >> >
> >> > This patch adds a new vhost port option, vhost-iommu-support, to
> >> > allow enablement of the vhost IOMMU feature:
> >> >
> >> > $ ovs-vsctl add-port br0 vhost-client-1 \
> >> > -- set Interface vhost-client-1 type=dpdkvhostuserclient \
> >> > options:vhost-server-path=$VHOST_USER_SOCKET_PATH \
> >> > options:vhost-iommu-support=true
> >> >
> >>
> >> Hi Mark, All,
> >>
> >> I'm thinking about this and whether the current approach provides
> >> more than what is actually needed by users at the cost of making the
> >> user interface more complex.
[Mooney, Sean K] I am personally split on this. To enable iommu support in
openstack with the above interface we would have to do two things. 1 extend the
image metatdata
or flavor extra specs to allow requesting a vIOMMU. Second we would have to
modify os-vif to produce
the add-port command above. Using this interfaces gives us a nice parity in our
api
as we only enable iommu support in ovs if we enable for qemu. E.g. if the
falvor/image does not request
a virtualized iommu we wont declare its support in the options.
> >>
> >> As an alternative, how about having a global other_config (to be set
> >> like vhost-socket-dir can be) for this instead of having to set it
> >> for each individual interface. It would mean that it would only have
> >> to be set once, instead of having this (ugly?!) option every time a
> >> vhost port is added, so it's a less intrusive change and I can't
> >> really think that a user would require to do this per vhostclient
[Mooney, Sean K] well one taught that instantly comes to mind is if I set
The global other_config option what happens if I do not request a iommu in qemu
Or I have an old qemu. If it would have any negative effect on network
connectivity
Or prevent the vm from functioning, that would require the nova scheduler to be
Aware of which node had this option set and take that into account when placing
vms.
I assume if it had no negative effects then we would not need a option, global
or per
Interface.
> >> interface??? It's pain to have to add this at all for a bug in QEMU
> >> and I'm sure in 1/2/3 years time someone will say that users could
> >> still be using QEMU < 2.9.1 and we can't remove it, so it would be
> >> nice to keep it as discreet as possible as we're going to be stuck
> with it for a while.
> >>
> >> I assume that a user would only use one version of QEMU at a time
> and
> >> would either want or not want this feature. In the worst case, if
> >> that proved completely wrong in the future, then a per interface
> >> override could easily be added. Once there's a way to maintain
> >> backwards compatibility (which there would be) I'd rather err on the
> >> side of introducing just enough enough functionality over increasing
> >> complexity for the user.
> >>
> >> What do you think?
[Mooney, Sean K] I'm not sure that a single qemu version is a valid assumption
to make.
At least in an OpenStack context where rolling upgrades are a thing. But you
are right
That it will be less common however if it was no existent we would not have the
issue with
Live migration between nodes with different feature sets that is also trying to
be addressed this
Cycle. If we add a global config option for iommu support that is yet another
thing that needs
To be accounted for during live migration.
> >>
> >> thanks,
> >> Kevin.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
