From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by dpdk.org (Postfix) with ESMTP id 1DB909394 for ; Tue, 5 Jan 2016 16:31:20 +0100 (CET) Received: by mail-io0-f173.google.com with SMTP id q21so189563636iod.0 for ; Tue, 05 Jan 2016 07:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KqMteGesyOUl6wR/w/mRYSjVHK5G7OqNgNLqmxlhLpY=; b=aHkeRzmjwiSR8rpb9zIB6nwdJHekN8sIbQw2ZRtE+ud/BH4u0CWd51Y4j2PgcBIBLR GwLRMaUhZ6YvxkZ0QqKNvA7vZZ7V/nfyUt0ZRLHHOCFW7CvXJNStPac1nyCAKL48D/co f7AuLlrw01FCr3Qut+b1jT31/txdMDwOTRpE+coSlGV+fUdLil52SmLY2/jBXTxxlfUJ poOgC7nw2mCGiEz0j9RrB6QLepn88p7Z5pJtHQrPY5861bIcePOfOj5TppP4d4zAgCVt JZTM5cWcizvwZjHFxYCAWlY9IA1F83CcMaBKwt9nbsJsE/nwn7FMdL84MLXWDtXSKOvl UtXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KqMteGesyOUl6wR/w/mRYSjVHK5G7OqNgNLqmxlhLpY=; b=Rpk3WpLjUWtNgZPahIDNIOkNMpUqKcAyD44KKtDeZNoTYn8B59595+Ku0DqcMUnDhP lY1j1yzRShQjJuZKiaCbVxm2hSUr4aexH/Jg3dCwM6yeBUfUQJdDhnD02rei601/Akdt BIMRqXrknRKeEwKndVrNurZE1FpYGr7VuzkvRDRhXOw5+xy98PVN1TCsJxJF4otX6iAz J4IEKDp5kecB/51kZpH8zaV4SBAIerpOYgKmrO7usl9XX+dRdO2ZiYUshhAeNqtkkzSs YOXEEbLXyTk9r8/ukUflceucKWxQWw3xVwZvigLqoiV5o5qfNammEc5ic/hrTTYfyaKw SZ8Q== X-Gm-Message-State: ALoCoQm63+J5/CaLoudXZEUmCkJZNwxq9eFlBQ6g4zzDpLxIQJjaeGwShNg1OaBB/3HxWy73AuYxm/TWhMuBnN5i4Oolz+TYiw== MIME-Version: 1.0 X-Received: by 10.107.169.225 with SMTP id f94mr84699582ioj.154.1452007879469; Tue, 05 Jan 2016 07:31:19 -0800 (PST) Received: by 10.64.108.229 with HTTP; Tue, 5 Jan 2016 07:31:19 -0800 (PST) Received: by 10.64.108.229 with HTTP; Tue, 5 Jan 2016 07:31:19 -0800 (PST) In-Reply-To: <568BC91D.8090806@intel.com> References: <1449249260-15165-1-git-send-email-stephen@networkplumber.org> <1449249260-15165-7-git-send-email-stephen@networkplumber.org> <20151204191831.GA20647@roosta.home> <568BC91D.8090806@intel.com> Date: Tue, 5 Jan 2016 07:31:19 -0800 Message-ID: From: Stephen Hemminger To: Declan Doherty Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org, Eric Kinzie Subject: Re: [dpdk-dev] [PATCH 6/8] bond: handle slaves with fewer queues than bonding device 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: Tue, 05 Jan 2016 15:31:20 -0000 A common usage scenario is to bond a vnic like virtio which typically has only a single rx queue with a VF device that has multiple receive queues. This is done to do live migration On Jan 5, 2016 05:47, "Declan Doherty" wrote: > On 04/12/15 19:18, Eric Kinzie wrote: > >> On Fri Dec 04 19:36:09 +0100 2015, Andriy Berestovskyy wrote: >> >>> Hi guys, >>> I'm not quite sure if we can support less TX queues on a slave that easy: >>> >>> queue_id = bond_slave_txqid(internals, i, bd_tx_q->queue_id); >>>> num_tx_slave = rte_eth_tx_burst(slaves[i], queue_id, >>>> slave_bufs[i], slave_nb_pkts[i]); >>>> >>> >>> It seems that two different lcores might end up writing to the same >>> slave queue at the same time, isn't it? >>> >>> Regards, >>> Andriy >>> >> >> Andriy, I think you're probably right about this. Perhaps it should >> instead refuse to add or refuse to activate a slave with too few >> tx queues. Could probably fix this with another layer of buffering >> so that an lcore with a valid tx queue could pick up the mbufs later, >> but this doesn't seem very appealing. >> >> Eric >> >> >> On Fri, Dec 4, 2015 at 6:14 PM, Stephen Hemminger >>> wrote: >>> >>>> From: Eric Kinzie >>>> >>>> In the event that the bonding device has a greater number of tx and/or >>>> rx >>>> queues than the slave being added, track the queue limits of the slave. >>>> On receive, ignore queue identifiers beyond what the slave interface >>>> can support. During transmit, pick a different queue id to use if the >>>> intended queue is not available on the slave. >>>> >>>> Signed-off-by: Eric Kinzie >>>> Signed-off-by: Stephen Hemminger >>>> --- >>>> >>> ... > > > I don't there is any straight forward way of supporting slaves with > different numbers of queues, the initial library was written with the > assumption that the number of tx/rx queues would always be the same on each > slave. This is why,when a slave is added to a bonded device we reconfigure > the queues. For features like RSS we have to have the same number of rx > queues otherwise the flow distribution to an application could change in > the case of a fail over event. Also by supporting different numbers of > queues between slaves we would be no longer be supporting the standard > behavior of ethdevs in DPDK were we expect that by using different queues > we don't require locking to be thread safe. > > >