From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by dpdk.org (Postfix) with ESMTP id 6E0BE28FD for ; Fri, 10 Jun 2016 20:13:18 +0200 (CEST) Received: by mail-pf0-f182.google.com with SMTP id t190so25493499pfb.3 for ; Fri, 10 Jun 2016 11:13:18 -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=h+EpNfbRQgSUAKGvpvMLOVRELbytl7q7OMjAqyI+qNg=; b=lUVLTqs8mBBWnDdaTL1xpZ0r5DTxd1zAJ2XnVc2o4U5TeklT8WJFuBtwHApu8Ns8PY ktCJdELKBF0klDUia1OttwgiFr0ubHBoS+YRvN/6BZilWNE3sesV81F7vznlE6g/KKjK skRpl1+rWQZ7NUjdYDhqBz7RzsCABU+ipVwpx1MJhua36tfubnCE8fe3nPWxh7yjk5In EuvJH8yixarx3nSrdcPEY0toLUfR80DnwFkl3nM7V0W3abjwFED+EL+kl9uNF5bvAKEe EeWLHZbbYU1Bdt0eNRDyLlFQOaPY5N4tS8DDK8lOngiB7pq7Kyc4EmW6+ry4jD7PaB0z v/Tg== 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=h+EpNfbRQgSUAKGvpvMLOVRELbytl7q7OMjAqyI+qNg=; b=QadUlD4gh1h/Grm/FzdYqaQzxT6mRqRH5I6C/kGZ8brAuvlRe/KLCDh8n/5/M98nqT 7/9HlP5rZsXVixLnOOJudBWNqANRAE5c8Qbv5FSejWYi/5X9Kf1iLTAKWdA6lkuGlhy+ pkEF87bGYj/NdiGvsJCAxDU/gMMakR+LNUi+Xc4ToleeDsCCSLGJ+9InmOUfSxDklenn aFSgc9LrkQNZYVZZc9v7PWHv29mmefzXabQMzL9z83iv+mVjzrAUVgGTcoehlJSZYhUi duO3VtyqsEElAv79qx4exnl10eUXrUe9oKAUMn08Zdf2kzWUoPPZlkgjHROksc+EoIP1 5r1Q== X-Gm-Message-State: ALyK8tIOn1NLgAuBI6ckDy6r8FhDJ97MmG1WtyYbBK3RhouKhytkUcaNzDoRfrM3QpDxyw== X-Received: by 10.98.213.2 with SMTP id d2mr3464574pfg.123.1465582397694; Fri, 10 Jun 2016 11:13:17 -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 q127sm19258683pfb.34.2016.06.10.11.13.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jun 2016 11:13:17 -0700 (PDT) Date: Fri, 10 Jun 2016 11:12:27 -0700 From: Stephen Hemminger To: "Lu, Wenzhuo" Cc: "dev@dpdk.org" , "Tao, Zhe" Message-ID: <20160610111227.4d9828f6@xeon-e3> In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC090903483A7F@shsmsx102.ccr.corp.intel.com> References: <1465191653-28408-1-git-send-email-wenzhuo.lu@intel.com> <1465191653-28408-3-git-send-email-wenzhuo.lu@intel.com> <20160607191553.10993efe@xeon-e3> <6A0DE07E22DDAD4C9103DF62FEBC090903483A7F@shsmsx102.ccr.corp.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: Fri, 10 Jun 2016 18:13:18 -0000 On Wed, 8 Jun 2016 07:34:43 +0000 "Lu, Wenzhuo" wrote: > > > > The fact that it requires lots more locking inside each device driver implies to me > > this is not correct way to architect this. > It's a good question. This patch set doesn't follow the regular assumption of DPDK. > But it's a requirement we've got from some customers. The users want the driver does as much as it can. The best is the link state change is transparent to the users. > The patch set tries to provide another choice if the users don't want to stop their rx/tx to handle the reset event. Then bring those uses to the development world (on users mailing list) and lets start the discussion there. The requirements creeping in through the backdoor also worries me.