From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 34EC7FE5 for ; Fri, 23 Oct 2015 10:02:09 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 23 Oct 2015 01:02:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,185,1444719600"; d="scan'208";a="670141161" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by orsmga003.jf.intel.com with ESMTP; 23 Oct 2015 01:02:04 -0700 Date: Fri, 23 Oct 2015 16:02:42 +0800 From: Yuanhan Liu To: "Michael S. Tsirkin" Message-ID: <20151023080242.GV3115@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> <20151022140710.GU3115@yliu-dev.sh.intel.com> <20151022171750-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151022171750-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: Fri, 23 Oct 2015 08:02:09 -0000 On Thu, Oct 22, 2015 at 05:19:01PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 22, 2015 at 10:07:10PM +0800, Yuanhan Liu wrote: > > 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? > > See tun_flow_update in drivers/net/tun.c in Linux. Thanks. We had a discussion today, and we need implement that. However, the v2.2 merge window is pretty near the end so far. So it's unlikely we could make it in this release. We may add it in v2.3. --yliu > > > > 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