> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@amd.com>
> Sent: Wednesday, October 19, 2022 21:49
> To: Guo, Junfeng <junfeng....@intel.com>; Zhang, Qi Z
> <qi.z.zh...@intel.com>; Wu, Jingjing <jingjing...@intel.com>
> Cc: ferruh.yi...@xilinx.com; dev@dpdk.org; Li, Xiaoyun
> <xiaoyun...@intel.com>; awogbem...@google.com; Richardson, Bruce
> <bruce.richard...@intel.com>; Lin, Xueqin <xueqin....@intel.com>
> Subject: Re: [PATCH v5 6/8] net/gve: add support for dev info get and dev
> configure
>
> On 10/10/2022 11:17 AM, Junfeng Guo wrote:
>
> >
> > Add dev_ops dev_infos_get.
> > Complete dev_configure with RX offloads configuration.
> >
> > Signed-off-by: Xiaoyun Li <xiaoyun...@intel.com>
> > Signed-off-by: Junfeng Guo <junfeng....@intel.com>
>
> <...>
>
> > --- a/drivers/net/gve/gve_ethdev.c
> > +++ b/drivers/net/gve/gve_ethdev.c
> > @@ -29,8 +29,16 @@ gve_write_version(uint8_t
> *driver_version_register)
> > }
> >
> > static int
> > -gve_dev_configure(__rte_unused struct rte_eth_dev *dev)
> > +gve_dev_configure(struct rte_eth_dev *dev)
> > {
> > + struct gve_priv *priv = dev->data->dev_private;
> > +
> > + if (dev->data->dev_conf.rxmode.mq_mode &
> RTE_ETH_MQ_RX_RSS_FLAG)
> > + dev->data->dev_conf.rxmode.offloads |=
> RTE_ETH_RX_OFFLOAD_RSS_HASH;
> > +
>
> This is force enabling the feature, we are doing this for PMDs that has
> the hash value anyway and no additional work or performance loss
> observed to enable this offload. Otherwise drivers shouldn't update
> 'dev_conf.rxmode'.
>
> Can you please confirm this PMD fits above description? And can you
> please add a coment that says force enabling the feature?
Yes, it seems force enabling this offloading is not quite reasonable here.
This may just follow previous PMD convention, so we decided to remove
this part in the coming version. Thanks!
>
> > + if (dev->data->dev_conf.rxmode.offloads &
> RTE_ETH_RX_OFFLOAD_TCP_LRO)
> > + priv->enable_rsc = 1;
> > +
> > return 0;
> > }
> >
> > @@ -94,6 +102,60 @@ gve_dev_close(struct rte_eth_dev *dev)
> > return err;
> > }
> >
> > +static int
> > +gve_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info
> *dev_info)
> > +{
> > + struct gve_priv *priv = dev->data->dev_private;
> > +
> > + dev_info->device = dev->device;
> > + dev_info->max_mac_addrs = 1;
> > + dev_info->max_rx_queues = priv->max_nb_rxq;
> > + dev_info->max_tx_queues = priv->max_nb_txq;
> > + dev_info->min_rx_bufsize = GVE_MIN_BUF_SIZE;
> > + dev_info->max_rx_pktlen = GVE_MAX_RX_PKTLEN;
> > + dev_info->max_mtu = RTE_ETHER_MTU;
>
> Can you please confirm max MTU this PMD supports is 1500? Meaning it
> doesn't support jumbo frames etc...
Actually here is just a workaround solution for the max_mtu info...
We can only get the max_mtu value via adminq message from the backend.
But the real one (i.e., priv->max_mtu) we get is 1460, which is less than 1500
Seems it is the GCP bug or something.
If we use "dev_info->max_mtu = priv->max_mtu", the testpmd cannot even
be launched successfully...
I'll keep this part unchanged with some comments here if no other solutions.
Please help correct me if you have any other idea. Thanks a lot!
>
> > + dev_info->min_mtu = RTE_ETHER_MIN_MTU;
> > +
> > + dev_info->rx_offload_capa = 0;
> > + dev_info->tx_offload_capa =
> > + RTE_ETH_TX_OFFLOAD_MULTI_SEGS |
> > + RTE_ETH_TX_OFFLOAD_IPV4_CKSUM |
> > + RTE_ETH_TX_OFFLOAD_UDP_CKSUM |
> > + RTE_ETH_TX_OFFLOAD_TCP_CKSUM |
> > + RTE_ETH_TX_OFFLOAD_SCTP_CKSUM |
> > + RTE_ETH_TX_OFFLOAD_TCP_TSO;
>
> Can you adverstise these capabilities in the patch that implements them?
Will move this to the corresponding patch, thanks!
