From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 8C721AD93 for ; Wed, 8 Jun 2016 04:15:39 +0200 (CEST) Received: by mail-pa0-f43.google.com with SMTP id hl6so4176250pac.2 for ; Tue, 07 Jun 2016 19:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=a8lVuIS0ndaaIMZT7bQ1bdjzWJdrwia2mFnp9m4E1LQ=; b=M9q3KqW013g/M9uvp9TYvbKl4X4w5mxvH1tKWFaX6CbjV60WzqeiYGPXvz4cfk7EbT xCqzXNyUcNNyi2Zksvtg/fQHA/ZFY1PNVECpTKzNF9WG2g/Uf6S3m0AiRkuYu7CUE0Mu 4areGQrYNajenmcDFYxBrmkJ0j3pC+OmO1U2PyrD79dQH2+Gbw1vbHRJRhz63jHBJscd ByLtndt0DzH/+sqZygPJ16EkmBOGAyE42mFjajoGfu145GmvIXzo/QodaDnJTC4LnpoM A+P5F3EMor0bOuvCJ7pSErC9Hb1KgvwE+i3uesY5ijw+0qz86SmwUCetj4JB42j5X2su mJEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=a8lVuIS0ndaaIMZT7bQ1bdjzWJdrwia2mFnp9m4E1LQ=; b=CTrhHRSOdHvoIrPa5pB0N+QqV6oLZC9VjFsj2MZ3xqWuSDpZuhX+yUnUm6EkTe7cQc iPFkqzDn1yNCnFQ46NWPqbbjvTf5hVVPuIriyrhHjqrddgPkCfuz9aiUt9ULcN1VivM/ 9Mbwd5lObzrtzzs0QvfsLcUOx95/Nf+XU7KSftgetqnwdx8Q1BKI6dXWtSdr3CSZVKWV ygkZRGd60Yti4d9iTP+EQrRYQTnbUd4q1kMzY1nfSQZrGfad3356cy9jC6VppN3+6go0 7kkzNbikYkFZLhX+pLsxTsf0QxlBkemHvXbF38+thIMuQIDpMuraPW255rT7tP8Z1C58 uf1Q== X-Gm-Message-State: ALyK8tKGPO6U9IsiL1Jnppi2kupps317B78qffwQKur0CXQIh+Kw5Y8SmtT1oG8tN+n8yg== X-Received: by 10.66.132.72 with SMTP id os8mr2854404pab.63.1465352138676; Tue, 07 Jun 2016 19:15:38 -0700 (PDT) Received: from xeon-e3 (static-50-53-69-251.bvtn.or.frontiernet.net. [50.53.69.251]) by smtp.gmail.com with ESMTPSA id 8sm38237081pfq.11.2016.06.07.19.15.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jun 2016 19:15:38 -0700 (PDT) Date: Tue, 7 Jun 2016 19:15:53 -0700 From: Stephen Hemminger To: Wenzhuo Lu Cc: dev@dpdk.org, Zhe Tao Message-ID: <20160607191553.10993efe@xeon-e3> In-Reply-To: <1465191653-28408-3-git-send-email-wenzhuo.lu@intel.com> References: <1465191653-28408-1-git-send-email-wenzhuo.lu@intel.com> <1465191653-28408-3-git-send-email-wenzhuo.lu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock mode 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: Wed, 08 Jun 2016 02:15:40 -0000 On Mon, 6 Jun 2016 13:40:47 +0800 Wenzhuo Lu wrote: > Define lock mode for RX/TX queue. Because when resetting > the device we want the resetting thread to get the lock > of the RX/TX queue to make sure the RX/TX is stopped. > > Using next ABI macro for this ABI change as it has too > much impact. 7 APIs and 1 global variable are impacted. > > Signed-off-by: Wenzhuo Lu > Signed-off-by: Zhe Tao Why does this patch set make a different assumption the rest of the DPDK? The rest of the DPDK operates on the principle that the application is smart enough to stop the device before making changes. There is no equivalent to the Linux kernel RTNL mutex. The API assumes application threads are well behaved and will not try and sabotage each other. If you restrict the reset operation to only being available when RX/TX is stopped, then no lock is needed. The fact that it requires lots more locking inside each device driver implies to me this is not correct way to architect this.