> >
> > snipped
> > > +static void
> > > +ice_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
> > > +*dev_info) {
> > > + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data-
> > >dev_private);
> > > + struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data-
> > > >dev_private);
> > > + struct ice_vsi *vsi = pf->main_vsi;
> > > + struct rte_pci_device *pci_dev = RTE_DEV_TO_PCI(dev->device);
> > > +
> > > + dev_info->min_rx_bufsize = ICE_BUF_SIZE_MIN;
> > > + dev_info->max_rx_pktlen = ICE_FRAME_SIZE_MAX;
> > > + dev_info->max_rx_queues = vsi->nb_qps;
> > > + dev_info->max_tx_queues = vsi->nb_qps;
> > > + dev_info->max_mac_addrs = vsi->max_macaddrs;
> > > + dev_info->max_vfs = pci_dev->max_vfs;
> > > +
> > > + dev_info->rx_offload_capa =
> > > +         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 =
> > > +         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 = 0;
> > > + dev_info->tx_queue_offload_capa = 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 features
> 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 for 
RX and TX. But you are stating in ice.ini you are listing offload supports. So 
let me rephrase the question 'if you support port level offload capability, 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 understanding?'

> 
> >
> > > +
> > > + dev_info->reta_size = hw->func_caps.common_cap.rss_table_size;
> > > + dev_info->hash_key_size = (VSIQF_HKEY_MAX_INDEX + 1) *
> > > sizeof(uint32_t);
> > > + dev_info->flow_type_rss_offloads = ICE_RSS_OFFLOAD_ALL;
> > > +
> > > + dev_info->default_rxconf = (struct rte_eth_rxconf) {
> > > +         .rx_thresh = {
> > > +                 .pthresh = ICE_DEFAULT_RX_PTHRESH,
> > > +                 .hthresh = ICE_DEFAULT_RX_HTHRESH,
> > > +                 .wthresh = ICE_DEFAULT_RX_WTHRESH,
> > > +         },
> > > +         .rx_free_thresh = ICE_DEFAULT_RX_FREE_THRESH,
> > > +         .rx_drop_en = 0,
> > > +         .offloads = 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 
disabled all packets will fall onto rx-queue-0. 

> 
> >
> > > + };
> > > +
> > > + dev_info->default_txconf = (struct rte_eth_txconf) {
> > > +         .tx_thresh = {
> > > +                 .pthresh = ICE_DEFAULT_TX_PTHRESH,
> > > +                 .hthresh = ICE_DEFAULT_TX_HTHRESH,
> > > +                 .wthresh = ICE_DEFAULT_TX_WTHRESH,
> > > +         },
> > > +         .tx_free_thresh = ICE_DEFAULT_TX_FREE_THRESH,
> > > +         .tx_rs_thresh = ICE_DEFAULT_TX_RSBIT_THRESH,
> > > +         .offloads = 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 configuration
> here.
Same as above

> 
> >
> > 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 returned 
correctly this I agree. But when the device is queried for capability it should 
highlight all supported speeds of switch. Am I right?

> 
> >
> > > + case ICE_AQ_LINK_SPEED_10MB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_10M;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_100MB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_100M;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_1000MB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_1G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_2500MB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_2_5G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_5GB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_5G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_10GB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_10G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_20GB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_20G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_25GB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_25G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_40GB:
> > > +         dev_info->speed_capa = ETH_LINK_SPEED_40G;
> > > +         break;
> > > + case ICE_AQ_LINK_SPEED_UNKNOWN:
> > > + default:
> > > +         PMD_DRV_LOG(ERR, "Unknown link speed");
> > > +         dev_info->speed_capa = 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

Reply via email to