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
| ||
|
Message-ID: <YzIdPWL1OWMjg6Ws@bullseye> Date: Mon, 26 Sep 2022 21:44:29 +0000 From: Bobby Eshleman <bobbyeshleman@...il.com> To: Stefano Garzarella <sgarzare@...hat.com> Cc: Bobby Eshleman <bobby.eshleman@...il.com>, Wei Liu <wei.liu@...nel.org>, Cong Wang <cong.wang@...edance.com>, Stephen Hemminger <sthemmin@...rosoft.com>, Bobby Eshleman <bobby.eshleman@...edance.com>, Jiang Wang <jiang.wang@...edance.com>, "Michael S. Tsirkin" <mst@...hat.com>, Dexuan Cui <decui@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, linux-kernel@...r.kernel.org, virtualization@...ts.linux-foundation.org, Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, Stefan Hajnoczi <stefanha@...hat.com>, kvm@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, linux-hyperv@...r.kernel.org, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH 0/6] virtio/vsock: introduce dgrams, sk_buff, and qdisc On Mon, Sep 26, 2022 at 03:42:19PM +0200, Stefano Garzarella wrote: > Hi, > > On Mon, Aug 15, 2022 at 10:56:03AM -0700, Bobby Eshleman wrote: > > Hey everybody, > > > > This series introduces datagrams, packet scheduling, and sk_buff usage > > to virtio vsock. > > Just a reminder for those who are interested, tomorrow Sep 27 @ 16:00 UTC we > will discuss more about the next steps for this series in this room: > https://meet.google.com/fxi-vuzr-jjb > (I'll try to record it and take notes that we will share) > > Bobby, thank you so much for working on this! It would be great to solve the > fairness issue and support datagram! > I appreciate that, thanks! > I took a look at the series, left some comments in the individual patches, > and add some advice here that we could pick up tomorrow: > - it would be nice to run benchmarks (e.g., iperf-vsock, uperf, etc.) to > see how much the changes cost (e.g. sk_buff use) > - we should take care also of other transports (i.e. vmci, hyperv), the > uAPI should be as close as possible regardless of the transport > Duly noted. I have some measurements with uperf, I'll put the data together and send that out here. Regarding the uAPI topic, I'll save that topic for our conversation tomorrow as I think the netdev topic will weigh on it. > About the use of netdev, it seems the most controversial point and I > understand Jakub and Michael's concerns. Tomorrow would be great if you can > update us if you have found any way to avoid it, just reusing a packet > scheduler somehow. > It would be great if we could make it available for all transports (I'm not > asking you to implement it for all, but to have a generic api that others > can use). > > But we can talk about that tomorrow! Sounds good, talk to you then! Best, Bobby
Powered by blists - more mailing lists