From: oulijun <oulijun@huawei.com> To: Ferruh Yigit <ferruh.yigit@intel.com>, dev <dev@dpdk.org> Cc: <linuxarm@openeuler.org>, "lihuisong (C)" <lihuisong@huawei.com> Subject: Re: [dpdk-dev] [RFC] some questions for speed_capa usage Date: Sat, 23 Jan 2021 17:06:50 +0800 Message-ID: <18e2c640-e5eb-ff55-9c79-6d6aac80f7d6@huawei.com> (raw) In-Reply-To: <1cc591cf-4217-7830-b496-934d0c0c8695@intel.com> 在 2021/1/18 19:23, Ferruh Yigit 写道: > On 1/18/2021 10:27 AM, oulijun wrote: >> Hi, >> >> >> The 'speed_capa' will be reported in rte_eth_dev_info_get API. How >> should users use the field? >> >> 1) The driver reports only the capabilities supported by the NIC, and >> users only obtain the capabilities. >> Maybe, there is a case that a rate bit in 'speed_capa' is not >> supported by the current transmission medium, >> such as, copper cable optical modules and optical interface modules. >> >> 2) The field is used only to inform users of the speed_capa supported >> by the current transmission medium. >> And users set the fixed speed or auto-negotiation by using >> 'link_speeds' according to the field. >> >> According to the existing implementations of all drivers, it seems >> that both of the above behaviors exist. >> >> How should we report and use it? >> > > Hi Lijun, > > When the driver reports the capabilities supported by the NIC, we tend > to mark this feature as partially supported. > > The expectation is the driver report the capability for the current > configuration, the PHY/FW/transmission medium, whatever it is. > > Driver should return the current supported values so that application > can select one, as you said. > Thank you for your answer. I see. > Regards, > ferruh > . >
prev parent reply other threads:[~2021-01-23 9:09 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-18 10:27 oulijun 2021-01-18 11:23 ` Ferruh Yigit 2021-01-23 9:06 ` oulijun [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=18e2c640-e5eb-ff55-9c79-6d6aac80f7d6@huawei.com \ --to=oulijun@huawei.com \ --cc=dev@dpdk.org \ --cc=ferruh.yigit@intel.com \ --cc=lihuisong@huawei.com \ --cc=linuxarm@openeuler.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
DPDK patches and discussions This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \ dev@dpdk.org public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git