From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 70984A00C4; Fri, 28 Oct 2022 17:14:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D20F40151; Fri, 28 Oct 2022 17:14:33 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1D9D040146 for ; Fri, 28 Oct 2022 17:14:32 +0200 (CEST) Received: from [192.168.1.39] (unknown [188.170.73.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 18E6B5E; Fri, 28 Oct 2022 18:14:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 18E6B5E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1666970071; bh=nnvtM2B7KTG6DI9hXh8zzkuldDArn725JBW7fqan+/Y=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=BJvONbZNhV5+bVvCXI5VPJTyg2Kg0ftxmfTOwXMEI50OjndUk8NXhZWgZIcyurSCm JMPnlyKrARQnfL9+JZc2FdMkYvpKrTR9UikF+z9q9WRDgvSdLuoE8t0LsfoNZJDnSB EWqKi0yWD2jLfyEW4ZBuVt0/ZfD52oQsBbNNOsN0= Message-ID: <07f7dc63-14f8-cc35-226b-3b4b124c6051@oktetlabs.ru> Date: Fri, 28 Oct 2022 18:14:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH v11 02/18] net/idpf: add support for device initialization From: Andrew Rybchenko To: Junfeng Guo , qi.z.zhang@intel.com, jingjing.wu@intel.com, beilei.xing@intel.com Cc: dev@dpdk.org, Xiaoyun Li , Xiao Wang References: <20221024130134.1046536-2-junfeng.guo@intel.com> <20221024131227.1062446-1-junfeng.guo@intel.com> <20221024131227.1062446-3-junfeng.guo@intel.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 10/25/22 11:57, Andrew Rybchenko wrote: > On 10/24/22 16:12, Junfeng Guo wrote: >> Support device init and add the following dev ops: >>   - dev_configure >>   - dev_close >>   - dev_infos_get >> >> Signed-off-by: Beilei Xing >> Signed-off-by: Xiaoyun Li >> Signed-off-by: Xiao Wang >> Signed-off-by: Junfeng Guo [snip] >> +struct idpf_adapter * >> +idpf_find_adapter(struct rte_pci_device *pci_dev) > > It looks like the function requires corresponding lock to be > held. If yes, it should be documented and code fixed. If no, > it should be explaiend why. I still don't understand it is a new patch. It is hardly safe to return a pointer to an element list when you drop lock. >> +    /* valid only if rxq_model is split Q */ >> +    uint16_t num_rx_bufq; >> + >> +    uint16_t max_mtu; > > unused Comments? It is still in place in a new version. >> +int >> +idpf_vc_get_caps(struct idpf_adapter *adapter) >> +{ >> +    struct virtchnl2_get_capabilities caps_msg; >> +    struct idpf_cmd_info args; >> +    int err; >> + >> +     memset(&caps_msg, 0, sizeof(struct virtchnl2_get_capabilities)); >> +     caps_msg.csum_caps = >> +         VIRTCHNL2_CAP_TX_CSUM_L3_IPV4        | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV4_TCP    | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV4_UDP    | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV4_SCTP    | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV6_TCP    | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV6_UDP    | >> +         VIRTCHNL2_CAP_TX_CSUM_L4_IPV6_SCTP    | >> +         VIRTCHNL2_CAP_TX_CSUM_GENERIC        | >> +         VIRTCHNL2_CAP_RX_CSUM_L3_IPV4        | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV4_TCP    | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV4_UDP    | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV4_SCTP    | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV6_TCP    | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV6_UDP    | >> +         VIRTCHNL2_CAP_RX_CSUM_L4_IPV6_SCTP    | >> +         VIRTCHNL2_CAP_RX_CSUM_GENERIC; >> + >> +     caps_msg.seg_caps = >> +         VIRTCHNL2_CAP_SEG_IPV4_TCP        | >> +         VIRTCHNL2_CAP_SEG_IPV4_UDP        | >> +         VIRTCHNL2_CAP_SEG_IPV4_SCTP        | >> +         VIRTCHNL2_CAP_SEG_IPV6_TCP        | >> +         VIRTCHNL2_CAP_SEG_IPV6_UDP        | >> +         VIRTCHNL2_CAP_SEG_IPV6_SCTP        | >> +         VIRTCHNL2_CAP_SEG_GENERIC; >> + >> +     caps_msg.rss_caps = >> +         VIRTCHNL2_CAP_RSS_IPV4_TCP        | >> +         VIRTCHNL2_CAP_RSS_IPV4_UDP        | >> +         VIRTCHNL2_CAP_RSS_IPV4_SCTP        | >> +         VIRTCHNL2_CAP_RSS_IPV4_OTHER        | >> +         VIRTCHNL2_CAP_RSS_IPV6_TCP        | >> +         VIRTCHNL2_CAP_RSS_IPV6_UDP        | >> +         VIRTCHNL2_CAP_RSS_IPV6_SCTP        | >> +         VIRTCHNL2_CAP_RSS_IPV6_OTHER        | >> +         VIRTCHNL2_CAP_RSS_IPV4_AH        | >> +         VIRTCHNL2_CAP_RSS_IPV4_ESP        | >> +         VIRTCHNL2_CAP_RSS_IPV4_AH_ESP        | >> +         VIRTCHNL2_CAP_RSS_IPV6_AH        | >> +         VIRTCHNL2_CAP_RSS_IPV6_ESP        | >> +         VIRTCHNL2_CAP_RSS_IPV6_AH_ESP; >> + >> +     caps_msg.hsplit_caps = >> +         VIRTCHNL2_CAP_RX_HSPLIT_AT_L2        | >> +         VIRTCHNL2_CAP_RX_HSPLIT_AT_L3        | >> +         VIRTCHNL2_CAP_RX_HSPLIT_AT_L4V4    | >> +         VIRTCHNL2_CAP_RX_HSPLIT_AT_L4V6; >> + >> +     caps_msg.rsc_caps = >> +         VIRTCHNL2_CAP_RSC_IPV4_TCP        | >> +         VIRTCHNL2_CAP_RSC_IPV4_SCTP        | >> +         VIRTCHNL2_CAP_RSC_IPV6_TCP        | >> +         VIRTCHNL2_CAP_RSC_IPV6_SCTP; >> + >> +     caps_msg.other_caps = >> +         VIRTCHNL2_CAP_RDMA            | >> +         VIRTCHNL2_CAP_SRIOV            | >> +         VIRTCHNL2_CAP_MACFILTER        | >> +         VIRTCHNL2_CAP_FLOW_DIRECTOR        | >> +         VIRTCHNL2_CAP_SPLITQ_QSCHED        | >> +         VIRTCHNL2_CAP_CRC            | >> +         VIRTCHNL2_CAP_WB_ON_ITR        | >> +         VIRTCHNL2_CAP_PROMISC            | >> +         VIRTCHNL2_CAP_LINK_SPEED        | >> +         VIRTCHNL2_CAP_VLAN; > > I'm wondering why all above capabilities are mentioned in the > patch? What does the API do? Do it is request it? Negotiage? Can I have answer on my question?