> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@amd.com>
> Sent: Thursday, October 20, 2022 19:20
> 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/20/2022 10:29 AM, Guo, Junfeng wrote:
> >
> >
> >> -----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!
> >
> 
> Getting actual value from device is correct thing to do, but it seems
> received value is not good, so OK to keep as it is.
> Can you please follow this with GVE?

Sure, will update this in the coming version. Thanks!

> 
> >>
> >>> +       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!
> >

Reply via email to