Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp305358ybz; Tue, 21 Apr 2020 09:20:50 -0700 (PDT) X-Google-Smtp-Source: APiQypLESafAnLTN7Z2fm5ronhBsVMSE430l39AuhPafLD1lS5jyN5FoiY2QczXbrLF3jJeIB4+j X-Received: by 2002:a17:906:af59:: with SMTP id ly25mr21952161ejb.65.1587486050224; Tue, 21 Apr 2020 09:20:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587486050; cv=none; d=google.com; s=arc-20160816; b=RTIOTXkmqC1gLr0tXoM8qYH95BaGx2ZUshfki001KFzetGdzFA/Lu6oo/6px8OIxd1 SHA0gj/51HP5swDlGFyghbRCpKwOTKrktkiEidkWNMBJNuDiV+JkVX3gy/liGF+K3MxU NcOENKXCmQrl3DiH87IWXxhYcx18bg/45Q6Nt1w8+PmSAg3W7n9AEVIY/LNRp2iMamII QhZCogO+rkR7tXciHuLAvCsOx/QsQE20I4GutXm9wzl141WCDoy3VcaECBvhXrxN0Yyz NDYTm7WZ+qiJba7/sFtAoaowAC1cQTpWVyr6pIVIrWZosWnyoTUsn4eYs+11v0GNvI0+ CzxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=6AGRVLAb8VV2GGBt9FCUOJrCOZqz3yE3pnkPMqPpaZ4=; b=XEMD6gFX9vpq9HRcgRacU4Yw5ibKbZMm6bSp1cNDKXo1LVY4pmblPtLD1oOatGkzOS OSvfHY33MU5DT5ibrX4W67C1NqK5+nolZ3orNmZRR5u2Evd2hJjZQSSXsZvH65fIUEUd c34WxTLbR7FVewr1Kvs7S/WU0hpZUjOB8QrAlvUwX1avyi70S/fswhrSYMzKX+F1AzVo 73QIHVf8wGve+bjD4H1GBX8QrFpKX1jxkjUzr6SNpkJsBvRgT7725u0dOZhly0JKlesC 6dA+pJVmzjyTuodvWRlGrDnp4k2IWeruxkuF79wciD4zeM7FT4df42goXtXGMjLfx7TP yFcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@redhat.com header.s=mimecast20190719 header.b=fLaw4mDF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m29si1856078eda.592.2020.04.21.09.20.25; Tue, 21 Apr 2020 09:20:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@redhat.com header.s=mimecast20190719 header.b=fLaw4mDF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726699AbgDUQRf (ORCPT + 99 others); Tue, 21 Apr 2020 12:17:35 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:20247 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726067AbgDUQRd (ORCPT ); Tue, 21 Apr 2020 12:17:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587485852; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6AGRVLAb8VV2GGBt9FCUOJrCOZqz3yE3pnkPMqPpaZ4=; b=fLaw4mDFAiAUyt3HFsE9oUivBaoPBLz8vYuBl+PmmSagFLVEAqoHwnl6pq0D7hd5Z2VwC6 k+3ZpIPdCpt3XJNxBWGgmThqT8hlPzGFfNlyFyLIIq+8sNEEPpq9grqrBRBIGdm3DaZRtd K99BwHoBHnJW3DSyFKc3FigvNbr3o7U= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-136-poYXOUfoNbi_rpL1ILAFTw-1; Tue, 21 Apr 2020 12:17:30 -0400 X-MC-Unique: poYXOUfoNbi_rpL1ILAFTw-1 Received: by mail-wr1-f71.google.com with SMTP id e5so7735187wrs.23 for ; Tue, 21 Apr 2020 09:17:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6AGRVLAb8VV2GGBt9FCUOJrCOZqz3yE3pnkPMqPpaZ4=; b=WanhnccgI/g6o2TUkU9wk65xXn92pnk85W7+q1U4UG3v33HhgCmNU4w/xG6Q23GTC+ /qebxAd6gBdPzCNZ/ESHX4xBjJqJRgQVd2Jo2iZYkEmiCDgRqPYbMjrlT9k6xgKOcIli X7T60P8bkkJmsya1Mt1Aw7B4GSqX+09Vw8kHJtJ/fxaMUBuuUX+2aCYMeqZ0lOpdrCXZ EM+bls7xMFdzWDH+3L30B9ix0IFvp+2aqZ28bD5WbvaJGunWl0jm8CT7BSR64EtPa4yE aZisIPaaybvZNHDeysHU13yBA7GMwNGEirgS+5jM3Zkk8qD+OoLpoASu0+WQvgtHJfny 5vhA== X-Gm-Message-State: AGi0PuYTQjQ23D+q2HVNysPxk9wGC/Gdi9QjIhc5+26O3rCDhtaP1oHT bCQxC+JvsHSQahpb7QTo5MyaXazg0jkgHNp0fjY6VSh5hlcbf55IYI7bPeYYI9qul6D490/x1E/ zA8/6K/pPqiCK4Udec7iUmcDV X-Received: by 2002:adf:db41:: with SMTP id f1mr23709660wrj.13.1587485849058; Tue, 21 Apr 2020 09:17:29 -0700 (PDT) X-Received: by 2002:adf:db41:: with SMTP id f1mr23709639wrj.13.1587485848793; Tue, 21 Apr 2020 09:17:28 -0700 (PDT) Received: from steredhat (host108-207-dynamic.49-79-r.retail.telecomitalia.it. [79.49.207.108]) by smtp.gmail.com with ESMTPSA id h2sm4500324wro.9.2020.04.21.09.17.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2020 09:17:27 -0700 (PDT) Date: Tue, 21 Apr 2020 18:17:24 +0200 From: Stefano Garzarella To: Stefan Hajnoczi Cc: davem@davemloft.net, Gerard Garcia , kvm@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Stefan Hajnoczi , Jakub Kicinski Subject: Re: [PATCH net] vsock/virtio: postpone packet delivery to monitoring devices Message-ID: <20200421161724.c3pnecltfz4jajww@steredhat> References: <20200421092527.41651-1-sgarzare@redhat.com> <20200421154246.GA47385@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200421154246.GA47385@stefanha-x1.localdomain> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 21, 2020 at 04:42:46PM +0100, Stefan Hajnoczi wrote: > On Tue, Apr 21, 2020 at 11:25:27AM +0200, Stefano Garzarella wrote: > > We delivering packets to monitoring devices, before to check if > > the virtqueue has enough space. > > "We [are] delivering packets" and "before to check" -> "before > checking". Perhaps it can be rewritten as: > > Packets are delivered to monitoring devices before checking if the > virtqueue has enough space. > Yeah, it is better :-) > > > > If the virtqueue is full, the transmitting packet is queued up > > and it will be sent in the next iteration. This causes the same > > packet to be delivered multiple times to monitoring devices. > > > > This patch fixes this issue, postponing the packet delivery > > to monitoring devices, only when it is properly queued in the > > s/,// > > > virqueue. > > s/virqueue/virtqueue/ > Thanks, I'll fix in the v2! > > @@ -137,6 +135,11 @@ virtio_transport_send_pkt_work(struct work_struct *work) > > break; > > } > > > > + /* Deliver to monitoring devices all correctly transmitted > > + * packets. > > + */ > > + virtio_transport_deliver_tap_pkt(pkt); > > + > > The device may see the tx packet and therefore receive a reply to it > before we can call virtio_transport_deliver_tap_pkt(). Does this mean > that replies can now appear in the packet capture before the transmitted > packet? hmm, you are right! And the same thing can already happen in vhost-vsock where we call virtio_transport_deliver_tap_pkt() after the vhost_add_used(), right? The vhost-vsock case can be fixed in a simple way, but here do you think we should serialize them? (e.g. mutex, spinlock) In this case I'm worried about performance. Or is there some virtqueue API to check availability? Thanks, Stefano