From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id E27D3683E for ; Thu, 6 Dec 2018 06:49:33 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2018 21:49:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,321,1539673200"; d="scan'208";a="257224566" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 05 Dec 2018 21:49:32 -0800 Received: from bgsmsx109.gar.corp.intel.com (10.223.4.211) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 21:49:32 -0800 Received: from bgsmsx101.gar.corp.intel.com ([169.254.1.20]) by BGSMSX109.gar.corp.intel.com ([169.254.10.187]) with mapi id 14.03.0415.000; Thu, 6 Dec 2018 11:19:29 +0530 From: "Varghese, Vipin" To: "Lu, Wenzhuo" , "dev@dpdk.org" CC: "Yang, Qiming" , "Li, Xiaoyun" , "Wu, Jingjing" Thread-Topic: [dpdk-dev] [PATCH v2 04/20] net/ice: support getting device information Thread-Index: AQHUitZN6TqqQNMXYUas+O8iSe96nqVuBSIAgALSIACAAGAB4A== Date: Thu, 6 Dec 2018 05:49:28 +0000 Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2D41C7@BGSMSX101.gar.corp.intel.com> References: <1542956179-80951-1-git-send-email-wenzhuo.lu@intel.com> <1543820821-108122-1-git-send-email-wenzhuo.lu@intel.com> <1543820821-108122-5-git-send-email-wenzhuo.lu@intel.com> <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2C4573@BGSMSX101.gar.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09093FE116C3@shsmsx102.ccr.corp.intel.com> In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093FE116C3@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWFlYTY4NGMtODAwMy00NjYwLTg5M2EtYTJhOTZlNWU0Y2MzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibSt1anlYbmZMSVVzZTVUd3BiQXo3dVM5eEJ1Uk1vWTVaQ0R2VExSQjBHXC96aTFYMjA1ZDFhV0lBNEJkNzlDXC9EIn0= dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.223.10.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 04/20] net/ice: support getting device information X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 05:49:34 -0000 > > > > snipped > > > +static void > > > +ice_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info > > > +*dev_info) { > > > + struct ice_pf *pf =3D ICE_DEV_PRIVATE_TO_PF(dev->data- > > >dev_private); > > > + struct ice_hw *hw =3D ICE_DEV_PRIVATE_TO_HW(dev->data- > > > >dev_private); > > > + struct ice_vsi *vsi =3D pf->main_vsi; > > > + struct rte_pci_device *pci_dev =3D RTE_DEV_TO_PCI(dev->device); > > > + > > > + dev_info->min_rx_bufsize =3D ICE_BUF_SIZE_MIN; > > > + dev_info->max_rx_pktlen =3D ICE_FRAME_SIZE_MAX; > > > + dev_info->max_rx_queues =3D vsi->nb_qps; > > > + dev_info->max_tx_queues =3D vsi->nb_qps; > > > + dev_info->max_mac_addrs =3D vsi->max_macaddrs; > > > + dev_info->max_vfs =3D pci_dev->max_vfs; > > > + > > > + dev_info->rx_offload_capa =3D > > > + DEV_RX_OFFLOAD_VLAN_STRIP | > > > + DEV_RX_OFFLOAD_IPV4_CKSUM | > > > + DEV_RX_OFFLOAD_UDP_CKSUM | > > > + DEV_RX_OFFLOAD_TCP_CKSUM | > > > + DEV_RX_OFFLOAD_QINQ_STRIP | > > > + DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM | > > > + DEV_RX_OFFLOAD_VLAN_EXTEND | > > > + DEV_RX_OFFLOAD_JUMBO_FRAME; > > > + dev_info->tx_offload_capa =3D > > > + DEV_TX_OFFLOAD_VLAN_INSERT | > > > + DEV_TX_OFFLOAD_QINQ_INSERT | > > > + DEV_TX_OFFLOAD_IPV4_CKSUM | > > > + DEV_TX_OFFLOAD_UDP_CKSUM | > > > + DEV_TX_OFFLOAD_TCP_CKSUM | > > > + DEV_TX_OFFLOAD_SCTP_CKSUM | > > > + DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM | > > > + DEV_TX_OFFLOAD_TCP_TSO; > > > + dev_info->rx_queue_offload_capa =3D 0; > > > + dev_info->tx_queue_offload_capa =3D 0; > > > > Does this mean per queue offload capability is not supported? If yes, > > can you mention this in release notes under 'support or limitation' > No, it's not supported. We have a document, ice.ini, to list all the feat= ures > supported. All the others are not supported. > BTW, I don't think anything not supported is limitation. If I understand correctly, ICE_DSI_PMD is advertising it has not offload f= or RX and TX. But you are stating in ice.ini you are listing offload suppor= ts. So let me rephrase the question 'if you support port level offload capa= bility, it will reflect for all queues rx and tx. But if you reflect queue = level offload as 0 for rx and tx, then APIs rte_eth_rx_queue_setup and rte_= eth_tx_queue_setup if queue offload enabled should fail. Is this correct un= derstanding?' >=20 > > > > > + > > > + dev_info->reta_size =3D hw->func_caps.common_cap.rss_table_size; > > > + dev_info->hash_key_size =3D (VSIQF_HKEY_MAX_INDEX + 1) * > > > sizeof(uint32_t); > > > + dev_info->flow_type_rss_offloads =3D ICE_RSS_OFFLOAD_ALL; > > > + > > > + dev_info->default_rxconf =3D (struct rte_eth_rxconf) { > > > + .rx_thresh =3D { > > > + .pthresh =3D ICE_DEFAULT_RX_PTHRESH, > > > + .hthresh =3D ICE_DEFAULT_RX_HTHRESH, > > > + .wthresh =3D ICE_DEFAULT_RX_WTHRESH, > > > + }, > > > + .rx_free_thresh =3D ICE_DEFAULT_RX_FREE_THRESH, > > > + .rx_drop_en =3D 0, > > > + .offloads =3D 0, > > Is drop function and rx_conf.offload supported ? If yes, if device is > > not configured then all offload should be set? > It's the default configuration. No matter a feature supported or not, it'= s not set > only means it's not enabled here. So, default behaviour is not to support drop_en. Incase of default RSS is d= isabled all packets will fall onto rx-queue-0.=20 >=20 > > > > > + }; > > > + > > > + dev_info->default_txconf =3D (struct rte_eth_txconf) { > > > + .tx_thresh =3D { > > > + .pthresh =3D ICE_DEFAULT_TX_PTHRESH, > > > + .hthresh =3D ICE_DEFAULT_TX_HTHRESH, > > > + .wthresh =3D ICE_DEFAULT_TX_WTHRESH, > > > + }, > > > + .tx_free_thresh =3D ICE_DEFAULT_TX_FREE_THRESH, > > > + .tx_rs_thresh =3D ICE_DEFAULT_TX_RSBIT_THRESH, > > > + .offloads =3D 0, > > > > If device is not configured, is not all offload be set true? > This a info_get function. I don't understand why we talk about configurat= ion > here. Same as above >=20 > > > > Snipped > > > > > + switch (hw->port_info->phy.link_info.link_speed) { > > > > If device switch is not configured (default value from NVM) should we > > highlight the switch can support speed 10, 100, 1000, 1000 and son on? > No, this's the capability getting from HW. If HW is supported or configured for 10, 100, 25G then those should be retu= rned correctly this I agree. But when the device is queried for capability = it should highlight all supported speeds of switch. Am I right? >=20 > > > > > + case ICE_AQ_LINK_SPEED_10MB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_10M; > > > + break; > > > + case ICE_AQ_LINK_SPEED_100MB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_100M; > > > + break; > > > + case ICE_AQ_LINK_SPEED_1000MB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_1G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_2500MB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_2_5G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_5GB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_5G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_10GB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_10G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_20GB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_20G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_25GB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_25G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_40GB: > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_40G; > > > + break; > > > + case ICE_AQ_LINK_SPEED_UNKNOWN: > > > + default: > > > + PMD_DRV_LOG(ERR, "Unknown link speed"); > > > + dev_info->speed_capa =3D ETH_LINK_SPEED_AUTONEG; > > > + break; > > > + } > > > > If speed is not true as stated above, can you please add this to > > release notes and documentation. > Here listed all the case we can get from HW. Please add to ice_dsi documentation also. snipped