From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id F2CC056A1 for ; Fri, 30 Mar 2018 15:48:13 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 78C5E218D2; Fri, 30 Mar 2018 09:48:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 30 Mar 2018 09:48:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=d8C90SJoCqeJ1yJsQye33ll/lfJ2zG1tohxrkdB1/nM=; b=a1pzM NzS/eJIOQsnXyj6/CilgNwaKVLMzYimK5xBrQIMT7YLH2FHSMBPJOc/PQQQrgnoC Q+zXqVx6CLzawU9mHA5anTcP6AzEEv+dWuvcmKs4/2loo8/0MjTSGMlzhDPledp+ 843XDx3y1rOnnctP7hk19zKgm4DAdJ8a7fQ2fo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=d8C90SJoCqeJ1yJsQye33ll/lfJ2z G1tohxrkdB1/nM=; b=Ru7n8Tk7km5vRJWiXI1iR1Sgcjc0Lq6N1oERvzsP41lIo W/m3cnExUExgMy5ndEHKEEav5+/241P0Myk1il21iJqQPZh2w3QJYaU/ucZZ90b4 p4kSvnG9JUkw7Ki1hfA4tIhCdP74th3kxw/9bn3FA2BRxhNU0umz51IjsHsURU1t IVCPIsds0uhe1BdIbT+S2N5DNDShsp1eYt9MUS91fjiVxBv8twvUM6luFDjgFvr3 EosxZH4sM9fkh7ycbLVrHSXQd4TZlFEPRfHnuhl+WBpJMh3o8RAe69XXShJXgMuv xpU7v2NLJlmacVQkeIbnr1lgzHTdvCS60xw9G1TEw== X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E5EC1026C; Fri, 30 Mar 2018 09:48:10 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: Ajit Khaparde , Jerin Jacob , Shijith Thotton , Santosh Shukla , Rahul Lakkireddy , John Daley , Wenzhuo Lu , Konstantin Ananyev , Beilei Xing , Qi Zhang , Jingjing Wu , Adrien Mazarguil , Nelio Laranjeiro , Yongseok Koh , Shahaf Shuler , Tomasz Duszynski , Jianbo Liu , Alejandro Lucero , Hemant Agrawal , Shreyansh Jain , Harish Patil , Rasesh Mody , Andrew Rybchenko , Shrikrishna Khare , Maxime Coquelin , Allain Legacy , Bruce Richardson , Gaetan Rivet , Olivier Matz Date: Fri, 30 Mar 2018 15:47:55 +0200 Message-ID: <2759953.P7QpFFSjiU@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-dev] Survey for final decision about per-port offload API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 13:48:14 -0000 There are some discussions about a specific part of the offload API: "To enable per-port offload, the offload should be set on both device configuration and queue setup." It means the application must repeat the port offload flags in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads, when calling respectively rte_eth_dev_configure() and rte_eth_[rt]x_queue_setup for each queue. The PMD must check if there is mismatch, i.e. a port offload not repeated in queue setup. There is a proposal to do this check at ethdev level: http://dpdk.org/ml/archives/dev/2018-March/094023.html It was also proposed to relax the API and allow "forgetting" port offloads in queue offloads: http://dpdk.org/ml/archives/dev/2018-March/092978.html It would mean the offloads applied to a queue result of OR operation: rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads 1/ Do you agree with above API change? If we agree with this change, we need to update the documentation and remove the checks in PMDs. Note: no matter what is decided here, 18.05-rc1 should have all PMDs switched to the API which was defined in 17.11. Given that API is new and not yet adopted by the applications, the sonner it is fixed, the better. 2/ Should we do this change in 18.05-rc2? At the same time, we want to make clear that an offload enabled at port level, cannot be disabled at queue level. 3/ Do you agree with above statement (to be added in the doc)? There is the same kind of confusion in the offload capabilities: rte_eth_dev_info.[rt]x_offload_capa rte_eth_dev_info.[rt]x_queue_offload_capa The queue capabilities must be a subset of port capabilities, i.e. every queue capabilities must be reported as port capabilities. But the port capabilities should be reported at queue level only if it can be applied to a specific queue. 4/ Do you agree with above statement (to be added in the doc)? Please give your opinion on questions 1, 2, 3 and 4. Answering by yes/no may be sufficient in most cases :) Thank you