Friday, 2019-06-21

*** eernst has joined #kata-dev01:42
*** eernst has quit IRC01:46
*** tmhoang has quit IRC02:04
*** pcaruana has joined #kata-dev04:45
*** sameo has joined #kata-dev04:50
stefanhasebastien.beouf: Today the absense of F_MQ doesn't matter for QEMU's vhost-user master implementation because struct vhost_dev->max_queues isn't used by anything in QEMU in the virtiofs case.  (It's only used by vhost_net.)05:18
stefanhasebastien.boeuf: But I think good practice is to extend libvhost-user to always set F_MQ and report 1 queue by default.  virtiofsd will tell libvhost-user to report more queues though, because as you say, even in the minimal configuration it has at 2 queues.05:18
stefanhasebastien.boeuf: This way virtiofsd will report the real number of queues and maybe other vhost-user master implementations will care about that.05:19
*** sameo has quit IRC06:56
*** jodh has joined #kata-dev07:23
*** sameo has joined #kata-dev07:43
*** jugs has quit IRC07:53
*** jugs has joined #kata-dev07:54
*** gwhaley has joined #kata-dev08:00
*** davidgiluk has joined #kata-dev08:07
kata-irc-bot<graham.whaley> @brtknr - I could try posting to the lists (but, lists are not normally the most happy things with attachements), or we could open an Issue on kata github to either just note or track progress. let me do that as a starter, coz it's easy ;)08:13
kata-irc-bot<graham.whaley> ah, actually @brtknr - I don't have details from @gmmaharaj of what hardware/setup that test was run on - so, I'm a little loathed to stick that on an Issue or list right now until we qualify that. If you want a copy thought for reference, send me a pm - firstname.lastname @ either intel or gmail.08:20
*** tmhoang has joined #kata-dev09:18
stefanhasebastien.beouf: I've CCed you on patches for libvhost-user VHOST_USER_PROTOCOL_F_MQ.  I'll also ping David Gilbert about rebasing virtiofsd on this.09:42
*** lpetrut has joined #kata-dev09:45
*** lpetrut has quit IRC10:10
*** lpetrut has joined #kata-dev10:10
*** gwhaley has quit IRC11:01
*** devimc has joined #kata-dev12:07
*** gwhaley has joined #kata-dev12:21
*** fuentess has quit IRC12:27
*** fuentess has joined #kata-dev12:30
*** fuentess has joined #kata-dev12:33
*** devimc has quit IRC12:58
kata-irc-bot<eric.ernst> Behavior change when moving to virtio-fs: https://github.com/kata-containers/runtime/issues/1818#issuecomment-50442844713:39
davidgilukeernst: I don't know k8s stuff, can you parse that for me - is that supposed to be a separate virtio-fs mount?13:44
*** jodh has quit IRC14:01
*** jodh has joined #kata-dev14:17
*** sameo has quit IRC14:31
*** lpetrut has quit IRC14:32
*** dklyle has joined #kata-dev14:37
*** gwhaley has quit IRC14:46
*** gwhaley has joined #kata-dev14:47
kata-irc-bot<sebastien.boeuf> stefanha: thanks, I'm gonna take a look15:32
kata-irc-bot<sebastien.boeuf> stefanha: btw, when you said "maybe other vhost-user master implementations will care about that.", that's exactly the case I'm trying to cover. The vhost crate pending implementation on rust-vmm expects the queue number to be provided when the master calls into get_queue_num()15:35
kata-irc-bot<sebastien.boeuf> there's a workaround to still have this working with virtio-fs, but I'd like to be able to remove eventually15:36
stefanhasebastien.boeuf: The spec doesn't prohibit using more than 1 queue.  There's just no way to query the maximum number of queues when F_MQ is missing.15:49
stefanhasebastien.boeuf: So I'd argue the vhost-user master implementation is too restrictive and shouldn't do that.  But then the vhost-user spec is quite ambiguous, so...15:51
kata-irc-bot<sebastien.boeuf> stefanha: yes we can definitely be more loose on the master implementation, but looking at the spec it is quite ambiguous as you just said. Look at this section "The max number of queue pairs the slave supports can be queried with message VHOST_USER_GET_QUEUE_NUM. Master should stop when the number of requested queues is bigger than that."15:53
*** clarkb has quit IRC15:53
kata-irc-bot<sebastien.boeuf> stefanha: so you're saying that because the spec does not say "must" instead of "can", the master does not have to ask for the number of queues15:53
kata-irc-bot<sebastien.boeuf> and because it knows the slave supports multiqueue, that should be enough15:54
kata-irc-bot<sebastien.boeuf> I feel the spec should be tightened a little bit15:54
stefanhasebastien.boeuf: No, there are two separate concepts.15:58
stefanhaRemember, vhost-net had multiple virtqueues before "multiqueue"!15:58
stefanhamultiqueue != multiple virtqueues15:58
stefanhamultiqueue == the device backend supports up to a maximum number of queues and you'll want to agree on how many to use15:58
stefanhamultiple virtqueues == most virtio devices have a fixed virtqueue layout but this doesn't require multiqueue15:59
*** sameo has joined #kata-dev15:59
stefanha(i.e. virtio-net had rx/tx/ctrl virtqueues and worked just fine without F_MQ)16:00
stefanhaIMO all modern device backends should advertise F_MQ but all masters should avoid relying on it where possible16:01
stefanhaThat way you get the best compatibility16:01
*** gwhaley has quit IRC16:05
*** jodh has quit IRC16:17
stefanhasebastien.boeuf: FWIW this is how I see it based on my research yesterday and this morning.  It's not some unwritten secret knowledge from the genesis of vhost-user.  It could be wrong :-).16:20
kata-irc-bot<sebastien.boeuf> stefanha: haha :slightly_smiling_face:16:29
kata-irc-bot<sebastien.boeuf> stefanha: thanks for the full explanation, this makes more sense to me, and I understand better the compatibility you're talking about16:29
kata-irc-bot<sebastien.boeuf> stefanha: you should look at/comment on https://github.com/rust-vmm/vhost/pull/216:31
stefanhasebastien.boeuf: Okay, thanks16:41
stefanhasebastien.boeuf: Do you know if the rust-vmm vhost-user master implementation makes any attempt to prevent the vhost device backend (aka slave) from blocking the master forever?17:06
stefanhasebastien.boeuf: QEMU's master wasn't designed with async in mind and at the protocol level I think there are places where unfortunately it has to be synchronous,17:07
stefanhabut it seems like a poor design to implement the master in a blocking fashion in places where it doesn't need to block.  Especially if that would hang other components of the VMM (management API, etc)...17:08
kata-irc-bot<sebastien.boeuf> stefanha: I don't know the answer for that, but I agree an async design would be neat17:10
kata-irc-bot<sebastien.boeuf> stefanha: thanks for commenting on vhost crate :slightly_smiling_face:17:10
stefanhasebastien.boeuf: trying to work my way through it :)17:13
*** kgz has quit IRC17:16
*** kragniz has joined #kata-dev17:19
*** kragniz is now known as kgz17:21
kata-irc-bot<sebastien.boeuf> stefanha: btw, I'm trying to have one kernel tree with both virtio-fs and virtio-pmem patches, but you rely on different kernel versions (virtio-fs is on 5.1 and virtio-pmem on 5.2)17:25
kata-irc-bot<sebastien.boeuf> any chance you have a 5.2-rcX tree somewhere for virtio-fs?17:25
*** igordc has joined #kata-dev17:25
kata-irc-bot<sebastien.boeuf> stefanha: nevermind, I just did the rebase, went pretty smooth, I had only one conflict18:05
stefanhasebastien.boeuf: vgoyal on #virtio-fs maintains the kernel tree and can help with rebases in the future.18:39
*** sameo has quit IRC19:15
*** davidgiluk has quit IRC19:33
*** pcaruana has quit IRC21:16
*** tmhoang has quit IRC21:20
*** fuentess has quit IRC21:51
*** igordc has quit IRC23:02
*** tmhoang has joined #kata-dev23:47

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!