From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 2A155BE12 for ; Tue, 16 Feb 2016 23:55:25 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id c200so185915099wme.0 for ; Tue, 16 Feb 2016 14:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/ZXY9M7YES7m5d1Jkh8oDleod6ozxO8O2tTnUl1A8Rk=; b=VbDiXg3xsFHnEGIHpAFygQaXhmEmZgzMYMchAZAS3g0mdDRStWJ44Z2dYitTiuaW3Z CRQLroosd0e2HdwMYnxA02w9CjFrRIKwMvNLqSoGmRa97FBfLE2JnlPVjUh9lOtG602s PHGCj9PKdD6CAegDW9gDW7sBf3xfVWnox9oghoUaQQjnR6bgBlpDMIAqQuMRhWbyaKts fcZ9JU3x/D4LdmVl+aXspk+kipqrXxqbPH97P0ubP3f6ikVLa52HmFrFkfIPR6+1E+We cy4ELUey1sPzeBOo/eO+FwsXu6Js9tp4XOqVyGqhH9MA8qWRrGdzvTChDdNcNn9J7yCY B/aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=/ZXY9M7YES7m5d1Jkh8oDleod6ozxO8O2tTnUl1A8Rk=; b=R72qUtULs0cjTDqyjp9vaEQj7E8GQ1JN3uqjPxsrdCpgeDAMsUVSiUmb2ItdDuQpCD 71HdUYw09j1je84ELXygTajT4kb/s5FhapfIg1AxpapMs7Cm4NKWGXeK0blyY33DHZiu jobZMvHeJJ9ytOuj+9NMM+JtXh4uCfEJwLufwRPSl3rF/B5vj6B0Y/AKk72/jEcjMkeu y9GZ5yNl1usENy1T9CLoCJ8XwW9OlBAppbqJAtxsuxTislqxX2RxnJW0b0sfBePTnQES GBNQLam/T/xDuBcDQDSxkk1cL5eJIm3BMRLMlf4GnoNuQAiz7cD16s7qAGKxICHGU31Y aF+A== X-Gm-Message-State: AG10YOSUpURb8pa+dA9t7fqCD2WTxi9dXKeCFq1fssKPJCb8m5a5Vbx8vgfxZFCqN6KFCBL1uKDesqspz3a5Xg== X-Received: by 10.28.150.69 with SMTP id y66mr20855685wmd.35.1455663325028; Tue, 16 Feb 2016 14:55:25 -0800 (PST) MIME-Version: 1.0 Sender: marc.sune@gmail.com Received: by 10.27.95.202 with HTTP; Tue, 16 Feb 2016 14:55:05 -0800 (PST) In-Reply-To: <56C2F9B0.5080204@cesnet.cz> References: <1454028127-10401-1-git-send-email-marcdevel@gmail.com> <1455488259-1000-1-git-send-email-marcdevel@gmail.com> <1455488259-1000-4-git-send-email-marcdevel@gmail.com> <56C2F9B0.5080204@cesnet.cz> From: Marc Date: Tue, 16 Feb 2016 23:55:05 +0100 X-Google-Sender-Auth: GUXUmpDrGsOFN6V9LMa6j-glnfY Message-ID: To: Matej Vido Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v8 3/4] ethdev: redesign link speed config API 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, 16 Feb 2016 22:55:25 -0000 Matej, On 16 February 2016 at 11:28, Matej Vido wrote: > D=C5=88a 14.02.2016 o 23:17 Marc Sune nap=C3=ADsal(a): > >> This patch redesigns the API to set the link speed/s configure >> for an ethernet port. Specifically: >> >> - it allows to define a set of advertised speeds for >> auto-negociation. >> - it allows to disable link auto-negociation (single fixed speed). >> - default: auto-negociate all supported speeds. >> >> Other changes: >> >> * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric >> values of all supported link speeds, in Mbps. >> * Converted link_speed to uint64_t to accomodate 100G speeds >> and beyond (bug). >> * Added autoneg flag in struct rte_eth_link to indicate if >> link speed was a result of auto-negociation or was fixed >> by configuration. >> * Added utility function to convert numeric speeds to bitmap >> fields. >> * Added rte_eth_speed_to_bm_flag() to version map. >> >> Signed-off-by: Marc Sune >> --- >> app/test-pipeline/init.c | 2 +- >> app/test-pmd/cmdline.c | 124 >> +++++++++++++++--------------- >> app/test-pmd/config.c | 4 +- >> app/test/virtual_pmd.c | 4 +- >> drivers/net/af_packet/rte_eth_af_packet.c | 5 +- >> drivers/net/bnx2x/bnx2x_ethdev.c | 8 +- >> drivers/net/bonding/rte_eth_bond_8023ad.c | 14 ++-- >> drivers/net/cxgbe/base/t4_hw.c | 8 +- >> drivers/net/cxgbe/cxgbe_ethdev.c | 2 +- >> drivers/net/e1000/em_ethdev.c | 116 >> ++++++++++++++-------------- >> drivers/net/e1000/igb_ethdev.c | 111 >> +++++++++++++------------- >> drivers/net/fm10k/fm10k_ethdev.c | 8 +- >> drivers/net/i40e/i40e_ethdev.c | 73 +++++++++--------- >> drivers/net/i40e/i40e_ethdev_vf.c | 11 +-- >> drivers/net/ixgbe/ixgbe_ethdev.c | 78 ++++++++----------- >> drivers/net/mlx4/mlx4.c | 6 +- >> drivers/net/mpipe/mpipe_tilegx.c | 6 +- >> drivers/net/nfp/nfp_net.c | 4 +- >> drivers/net/null/rte_eth_null.c | 5 +- >> drivers/net/pcap/rte_eth_pcap.c | 9 ++- >> drivers/net/ring/rte_eth_ring.c | 5 +- >> drivers/net/virtio/virtio_ethdev.c | 2 +- >> drivers/net/virtio/virtio_ethdev.h | 2 - >> drivers/net/vmxnet3/vmxnet3_ethdev.c | 5 +- >> drivers/net/xenvirt/rte_eth_xenvirt.c | 5 +- >> examples/ip_pipeline/config_parse.c | 3 +- >> lib/librte_ether/rte_ethdev.c | 49 ++++++++++++ >> lib/librte_ether/rte_ethdev.h | 113 >> +++++++++++++++++---------- >> lib/librte_ether/rte_ether_version.map | 6 ++ >> 29 files changed, 443 insertions(+), 345 deletions(-) >> >> [...] >> > > Hi, > > some drivers (at least: e1000, i40e, ixgbe, mpipe, nfp, virtio, vmxnet3) > use rte_atomic64_cmpset() to read and write link state like: > > static inline int > rte_em_dev_atomic_read_link_status(struct rte_eth_dev *dev, > struct rte_eth_link *link) > { > struct rte_eth_link *dst =3D link; > struct rte_eth_link *src =3D &(dev->data->dev_link); > > if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst, > *(uint64_t *)src) =3D=3D 0) > return -1; > > return 0; > } > > static inline int > rte_em_dev_atomic_write_link_status(struct rte_eth_dev *dev, > struct rte_eth_link *link) > { > struct rte_eth_link *dst =3D &(dev->data->dev_link); > struct rte_eth_link *src =3D link; > > if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst, > *(uint64_t *)src) =3D=3D 0) > return -1; > > return 0; > } > > > When link_speed is changed to uint64_t, struct rte_eth_link exceeds 64 > bits. Shouldn't these functions be adapted in this patch series? > > Szedata2 PMD will also use rte_atomic64_cmpset() after patch [1]. > I can take care of this change in szedata2 PMD when patch [1] is accepted > together with adjusting speeds in szedata2 PMD. > Indeed, thanks. I will take care of them in v9 (incl. szedata2). marc > [1] http://dpdk.org/ml/archives/dev/2016-January/032281.html > > Regards, > Matej >