From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 977B65686 for ; Wed, 23 Nov 2016 16:26:49 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 23 Nov 2016 07:26:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,538,1473145200"; d="scan'208";a="1063306072" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga001.jf.intel.com with ESMTP; 23 Nov 2016 07:26:47 -0800 To: Andrew Rybchenko , dev@dpdk.org References: <1479740470-6723-1-git-send-email-arybchenko@solarflare.com> <1479740470-6723-33-git-send-email-arybchenko@solarflare.com> From: Ferruh Yigit Message-ID: <76a60072-2c7b-b674-ca7f-1dc9ca66815a@intel.com> Date: Wed, 23 Nov 2016 15:26:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <1479740470-6723-33-git-send-email-arybchenko@solarflare.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 32/56] net/sfc: implement driver operation to init device on attach 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, 23 Nov 2016 15:26:50 -0000 On 11/21/2016 3:00 PM, Andrew Rybchenko wrote: > The setup and configuration of the PMD is not performance sensitive, > but is not thread safe either. It is possible that the multiple > read/writes during PMD setup and configuration could be corrupted > in a multi-thread environment. Right, this is not thread-safe, but this is valid for all PMDs, it is not expected to have initialization in multi-threaded environment, that said so, synchronization also won't hurt, as you said this is not fast path, just may not be necessary. > Since this is not performance > sensitive, the developer can choose to add their own layer to provide > thread-safe setup and configuration. It is expected that, in most > applications, the initial configuration of the network ports would be > done by a single thread at startup. > > Reviewed-by: Andy Moreton > Signed-off-by: Andrew Rybchenko <...> > diff --git a/drivers/net/sfc/efx/sfc_ethdev.c b/drivers/net/sfc/efx/sfc_ethdev.c > index 0deff07..e5b609c 100644 > --- a/drivers/net/sfc/efx/sfc_ethdev.c > +++ b/drivers/net/sfc/efx/sfc_ethdev.c > @@ -31,6 +31,8 @@ > #include > #include > > +#include "efx.h" > + > #include "sfc.h" > #include "sfc_debug.h" > #include "sfc_log.h" > @@ -55,6 +57,8 @@ sfc_eth_dev_init(struct rte_eth_dev *dev) > struct sfc_adapter *sa = dev->data->dev_private; > struct rte_pci_device *pci_dev = dev->pci_dev; > int rc; > + const efx_nic_cfg_t *encp; > + const struct ether_addr *from; > > /* Required for logging */ > sa->eth_dev = dev; > @@ -73,11 +77,43 @@ sfc_eth_dev_init(struct rte_eth_dev *dev) > > sfc_log_init(sa, "entry"); > > + dev->data->mac_addrs = rte_zmalloc("sfc", ETHER_ADDR_LEN, 0); > + if (dev->data->mac_addrs == NULL) { > + rc = ENOMEM; > + goto fail_mac_addrs; > + } > + > + sfc_adapter_lock_init(sa); > + sfc_adapter_lock(sa); > + > + sfc_log_init(sa, "attaching"); > + rc = sfc_attach(sa); > + if (rc != 0) > + goto fail_attach; > + > + encp = efx_nic_cfg_get(sa->nic); > + > + /* > + * The arguments are really reverse order in comparison to > + * Linux kernel. Copy from NIC config to Ethernet device data. > + */ Yes it is J, and agreed this is confusing. > + from = (const struct ether_addr *)(encp->enc_mac_addr); > + ether_addr_copy(from, &dev->data->mac_addrs[0]); > + <...>