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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 AA268C02198 for ; Fri, 14 Feb 2025 09:43:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5D1884115B; Fri, 14 Feb 2025 09:43:37 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id ltWZ9es-m3LO; Fri, 14 Feb 2025 09:43:35 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 44EA040CA9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1739526215; bh=YkAOUtv2YEZdGJYB6NrZGnlKOR+POSND0NgA/1BEXAc=; h=Date:To:Cc:References:From:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KYb30jUxIMFBhGoiHEm415PPr/ux/Qvr3P7GWMoFQUeadyiSvOvYUxy7fd7BESUxx nJXVtoajwjYYLjrwADHFYntOAZwwPgbBV+1+75vE/7Lb511psfpOqqOnk+nwqK4gUN nkCQtOFtc/xCU4FnaJAo+i2rzyeInc1Vn66edfVPy6FlcTvDtONJubA9kU6pRyvmxD h+WK4ow22UN648dy0zoeDBAVOJgMdO3RT3HZfjo5490CC0d4NUyvWEolGIUTtAuO48 2dvtP1zN3CGO3Cjn5xa1yp+o+h1wncXGJSyPvLQ/Fp+TH6hL3oBdiPwx0VaWn0v/0b 42REFKrZ8NNLA== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp4.osuosl.org (Postfix) with ESMTP id 44EA040CA9; Fri, 14 Feb 2025 09:43:35 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists1.osuosl.org (Postfix) with ESMTP id AA855C2 for ; Fri, 14 Feb 2025 09:43:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8E84783696 for ; Fri, 14 Feb 2025 09:43:33 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id iPGnWRd3FsGp for ; Fri, 14 Feb 2025 09:43:32 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=192.198.163.12; helo=mgamail.intel.com; envelope-from=faizal.abdul.rahim@linux.intel.com; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp1.osuosl.org 0B8848146D DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0B8848146D Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by smtp1.osuosl.org (Postfix) with ESMTPS id 0B8848146D for ; Fri, 14 Feb 2025 09:43:31 +0000 (UTC) X-CSE-ConnectionGUID: E+5M3vceS2mcMrv59vQQ8Q== X-CSE-MsgGUID: hmVYPvhqRvWKbiLTqggvDg== X-IronPort-AV: E=McAfee;i="6700,10204,11344"; a="44197300" X-IronPort-AV: E=Sophos;i="6.13,285,1732608000"; d="scan'208";a="44197300" 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 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-Mailman-Original-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-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dmarc=none (p=none dis=none) header.from=linux.intel.com X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=ViFKXovg Subject: Re: [Intel-wired-lan] [PATCH iwl-next v4 0/9] igc: Add support for Frame Preemption feature in IGC X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" 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.