From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8A7CFA10DA for ; Fri, 2 Aug 2019 20:17:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B9B5B1C2A4; Fri, 2 Aug 2019 20:17:57 +0200 (CEST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by dpdk.org (Postfix) with ESMTP id 35F331C212 for ; Fri, 2 Aug 2019 20:17:55 +0200 (CEST) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x72I6rki015344; Fri, 2 Aug 2019 14:17:52 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 2u4sbhjfhv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Aug 2019 14:17:52 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x72IBBCp001106; Fri, 2 Aug 2019 18:17:51 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma03dal.us.ibm.com with ESMTP id 2u0e87fm44-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Aug 2019 18:17:51 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x72IHo2149217796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Aug 2019 18:17:50 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A6547136051; Fri, 2 Aug 2019 18:17:50 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5AAD5136055; Fri, 2 Aug 2019 18:17:50 +0000 (GMT) Received: from davids-mbp.randomparity.local (unknown [9.163.40.47]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 2 Aug 2019 18:17:50 +0000 (GMT) To: Slava Ovsiienko Cc: "dev@dpdk.org" References: <1564612871-162495-1-git-send-email-drc@linux.vnet.ibm.com> From: David Christensen Message-ID: Date: Fri, 2 Aug 2019 11:17:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-02_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=772 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908020190 Subject: Re: [dpdk-dev] [PATCH] net/mlx5: txq_inline_min not set for ConnectX-5 adapters 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >>> Yes, thank you for the patch, acked. >>> >>> The "txq_inline_min" value was not set for ConnectX-5 to 0 as default. >>> At the TX queue setup time the "txq_inline_min" is checked against >>> MLX5_ARG_UNSET and default value 0 is set: >>> >>> txq_set_params() >>> ... >>> inlen_mode = (config->txq_inline_min == MLX5_ARG_UNSET) ? >>> 0 : (unsigned int)config->txq_inline_min; >>> >>> So, there should be no negative backwards. Did you observe any? >> >> The gdb session below shows how the value is unchanged after passing >> through mlx5_set_min_inline on my system without the change. > > Yes, mlx5_set_min_inline() does not set txq_inline_min by default. > So, your patch is OK. > > I mean the actual inline_len is set to 0 before actual usage in txq_set_params() > routine, so not setting config->txq_inline_min to default zero should not cause > negative backwards. So that implies the assert to verify that txq_inline_min >= 0 in mlx5_set_txlimit_params() is unnecessary. Should the patch change and just remove the assert? I think the patch is the more logical solution, setting the value at the source similar to what's done for all other adapters. Dave