From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A036BC02198 for ; Fri, 14 Feb 2025 09:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YkAOUtv2YEZdGJYB6NrZGnlKOR+POSND0NgA/1BEXAc=; b=fKZAsXEi3fslz5fwsl2w+bd3HY pguW+Kci3ODkNzhbU0vadASVF6z6vLnWfdbdFG5UwOMwBH6cMSh/nU/MDuds+LtkkBZOhVKvN5B2K nTgDHHQjSM0gu+bdGpiv8K1+VoqBOTShjt2c5PGFlMKNeEuoLVgPSzCrFPWG7A6uRokOxSJoJ19cl dkPKfXnMhlmH4j7TbU0g7pDoQp7OcKhXShHNpd6Gbtvm8fPK7BUGb6KI2X0q86Zywsy6w7FJCp+6G l9bRuVA0+vf7CbV0fAJrODnTBH9g/PtAtq36ZpEATX7ZaSfb0at3efvpl+ol8ZcwVk8y+xef2xyus wV3hx1VQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tisIt-0000000ENsI-3WOn; Fri, 14 Feb 2025 09:48:11 +0000 Received: from mgamail.intel.com ([192.198.163.12]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tisEO-0000000EN0b-3Hku for linux-arm-kernel@lists.infradead.org; Fri, 14 Feb 2025 09:43:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739526212; x=1771062212; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=zLq34zyZ+vn2x8EHLG71uh1H2EfQ4PWpqK69Hy66e7w=; b=ViFKXovgOXOFScFg8+GYrAxPhRy9KrENocku7RpenrL9BzfXvYfaAZRg jQBm7hnEPZCmZFwxjmlZhA1z7C884dKiyWJRzLl8bO3TkrMIBK4CjR3kQ iqurHJTYsCdnfougLXc2YPBCsTovqq8GIgRYMPsOzAkv0cquC2S4DIMU+ oOMT3Z1Oe+9e+snzMOfYflKKKQ5C+P8mZeM5socKzbvrqA9r2vppzVmzq WVFF52dfBY+NX/AymnmuoDXRS5tYSoHjzijwYsnEPB/LzYD6/3AYtu8Ig DU1IYpzd/u+Tz0eUOkYtwsCAcpc0pPEI4dRofM6FLOeWYPi9UrF1cONln g==; X-CSE-ConnectionGUID: SKIKLVkJQaip+ODL3pAFvw== X-CSE-MsgGUID: +zw9WfDpRvGU/5QlTuCwUA== X-IronPort-AV: E=McAfee;i="6700,10204,11344"; a="44197305" X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208";a="44197305" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 01:43:30 -0800 X-CSE-ConnectionGUID: ZO0UWXkJQOin2e28wbPaEw== X-CSE-MsgGUID: Hg2vL6gvSzaFtD29bl+/3A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="118036852" Received: from mohdfai2-mobl.gar.corp.intel.com (HELO [10.247.89.75]) ([10.247.89.75]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 01:43:22 -0800 Message-ID: <641ab972-e110-4af2-ad9b-6688cee56562@linux.intel.com> Date: Fri, 14 Feb 2025 17:43:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC To: Kurt Kanzenbach , Vladimir Oltean Cc: Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , Simon Horman , Russell King , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Furong Xu <0x1207@gmail.com>, Russell King , Serge Semin , Xiaolei Wang , Suraj Jaiswal , Kory Maincent , Gal Pressman , Jesper Nilsson , Andrew Halaney , Choong Yong Liang , Kunihiko Hayashi , Vinicius Costa Gomes , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org References: <20250210070207.2615418-1-faizal.abdul.rahim@linux.intel.com> <20250210070207.2615418-1-faizal.abdul.rahim@linux.intel.com> <20250212220121.ici3qll66pfoov62@skbuf> <87cyfmnjdh.fsf@kurt.kurt.home> <5902cc28-a649-4ae9-a5ba-83aa265abaf8@linux.intel.com> <20250213130003.nxt2ev47a6ppqzrq@skbuf> <1c981aa1-e796-4c53-9853-3eae517f2f6d@linux.intel.com> <877c5undbg.fsf@kurt.kurt.home> <20250213184613.cqc2zhj2wkaf5hn7@skbuf> <87v7td3bi1.fsf@kurt.kurt.home> <874j0wrjk2.fsf@kurt.kurt.home> Content-Language: en-US From: "Abdul Rahim, Faizal" In-Reply-To: <874j0wrjk2.fsf@kurt.kurt.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250214_014332_838970_5AACB82C X-CRM114-Status: GOOD ( 19.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 14/2/2025 4:56 pm, Kurt Kanzenbach wrote: > On Fri Feb 14 2025, Abdul Rahim, Faizal wrote: >> On 14/2/2025 3:12 am, Kurt Kanzenbach wrote: >>> On Thu Feb 13 2025, Vladimir Oltean wrote: >>>> So, confusingly to me, it seems like one operating mode is fundamentally >>>> different from the other, and something will have to change if both will >>>> be made to behave the same. What will change? You say mqprio will behave >>>> like taprio, but I think if anything, mqprio is the one which does the >>>> right thing, in igc_tsn_tx_arb(), and taprio seems to use the default Tx >>>> arbitration scheme? >>> >>> Correct. taprio is using the default scheme. mqprio configures it to >>> what ever the user provided (in igc_tsn_tx_arb()). >>> >>>> I don't think I'm on the same page as you guys, because to me, it is >>>> just odd that the P traffic classes would be the first ones with >>>> mqprio, but the last ones with taprio. >>> >>> I think we are on the same page here. At the end both have to behave the >>> same. Either by using igc_tsn_tx_arb() for taprio too or only using the >>> default scheme for both (and thereby keeping broken_mqprio). Whatever >>> Faizal implements I'll match the behavior with mqprio. >>> >> >> Hi Kurt & Vladimir, >> >> After reading Vladimir's reply on tc, hw queue, and socket priority mapping >> for both taprio and mqprio, I agree they should follow the same priority >> scheme for consistency—both in code and command usage (i.e., taprio, >> mqprio, and fpe in both configurations). Since igc_tsn_tx_arb() ensures a >> standard mapping of tc, socket priority, and hardware queue priority, I'll >> enable taprio to use igc_tsn_tx_arb() in a separate patch submission. > > There's one point to consider here: igc_tsn_tx_arb() changes the mapping > between priorities and Tx queues. I have no idea how many people rely on > the fact that queue 0 has always the highest priority. For example, it > will change the Tx behavior for schedules which open multiple traffic > classes at the same time. Users may notice. Yeah, I was considering the impact on existing users too. I hadn’t given it much thought initially and figured they’d just need to adapt to the changes, but now that I think about it, properly communicating this would be tough. taprio on igc (i225, i226) has been around for a while, so a lot of users would be affected. > OTOH changing mqprio to the broken_mqprio model is easy, because AFAIK > there's only one customer using this. > Hmmmm, now I’m leaning toward keeping taprio as is (hw queue 0 highest priority) and having mqprio follow the default priority scheme (aka broken_mqprio). Even though it’s not the norm, the impact doesn’t seem worth the gain. Open to hearing others' thoughts.