From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id D8F4593F4 for ; Thu, 22 Oct 2015 16:07:08 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 22 Oct 2015 07:06:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,182,1444719600"; d="scan'208";a="800210492" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by orsmga001.jf.intel.com with ESMTP; 22 Oct 2015 07:06:40 -0700 Date: Thu, 22 Oct 2015 22:07:10 +0800 From: Yuanhan Liu To: "Michael S. Tsirkin" Message-ID: <20151022140710.GU3115@yliu-dev.sh.intel.com> References: <1445399294-18826-1-git-send-email-yuanhan.liu@linux.intel.com> <1445399294-18826-5-git-send-email-yuanhan.liu@linux.intel.com> <20151021133043-mutt-send-email-mst@redhat.com> <20151021124815.GG3115@yliu-dev.sh.intel.com> <20151021172336-mutt-send-email-mst@redhat.com> <20151022094955.GR3115@yliu-dev.sh.intel.com> <20151022142141-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151022142141-mutt-send-email-mst@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dev@dpdk.org, marcel@redhat.com Subject: Re: [dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 14:07:09 -0000 On Thu, Oct 22, 2015 at 02:32:31PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 22, 2015 at 05:49:55PM +0800, Yuanhan Liu wrote: > > On Wed, Oct 21, 2015 at 05:26:18PM +0300, Michael S. Tsirkin wrote: > > > On Wed, Oct 21, 2015 at 08:48:15PM +0800, Yuanhan Liu wrote: > > > > > Please note that for virtio devices, guest is supposed to > > > > > control the placement of incoming packets in RX queues. > > > > > > > > I may not follow you. > > > > > > > > Enqueuing packets to a RX queue is done at vhost lib, outside the > > > > guest, how could the guest take the control here? > > > > > > > > --yliu > > > > > > vhost should do what guest told it to. > > > > > > See virtio spec: > > > 5.1.6.5.5 Automatic receive steering in multiqueue mode > > > > Spec says: > > > > After the driver transmitted a packet of a flow on transmitqX, > > the device SHOULD cause incoming packets for that flow to be > > steered to receiveqX. > > > > > > Michael, I still have no idea how vhost could know the flow even > > after discussion with Huawei. Could you be more specific about > > this? Say, how could guest know that? And how could guest tell > > vhost which RX is gonna to use? > > > > Thanks. > > > > --yliu > > I don't really understand the question. > > When guests transmits a packet, it makes a decision > about the flow to use, and maps that to a tx/rx pair of queues. > > It sends packets out on the tx queue and expects device to > return packets from the same flow on the rx queue. > > During transmit, device needs to figure out the flow > of packets as they are received from guest, and track > which flows go on which tx queue. > When it selects the rx queue, it has to use the same table. Thanks for the length explanation, Michael! I guess the key is are we able to get the table inside vhost-user lib? And, are you looking for something like following? static int rte_vhost_enqueue_burst(pkts) { for_each_pkts(pkt) { int rxq = get_rxq_from_table(pkt); queue_to_rxq(pkt, rxq); } } BTW, there should be such implementation at some where, right? If so, would you please point it to me? In the meanwhile, I will read more doc/code to try to understand it. --yliu > > There is currently no provision for controlling > steering for uni-directional > flows which are possible e.g. with UDP. > > We might solve this in a future spec - for example, set a flag notifying > guest that steering information is missing for a given flow, for example > by setting a flag in a packet, or using the command queue, and have > guest send a dummy empty packet to set steering rule for this flow. > > > -- > MST