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 301E143410; Thu, 30 Nov 2023 12:25:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1ACD442E97; Thu, 30 Nov 2023 12:25:28 +0100 (CET) Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by mails.dpdk.org (Postfix) with ESMTP id 1091342E8F for ; Thu, 30 Nov 2023 12:25:27 +0100 (CET) Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-2856437b584so759158a91.3 for ; Thu, 30 Nov 2023 03:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; t=1701343526; x=1701948326; darn=dpdk.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=GDbsT3Sdr0VPEfLE4bfaBSqvIQva1DgTNiHkOioKC3M=; b=AtRC6lcKbLWWXPYqjxOX7/LEQsx+Pg7JuzhezCr/fenAqQVscNVjMzPTAW4JYeeizV +c4f8fJxkFSlthPXEqWBZTvgAZopnfn1nGsbPTqZccaJMsfJ5lpVRysUOGpKEViR2npn GxWh5xW6l3bF/hCx3rVjcSBNuv6EKZiBrQfcDs8bTu8YTlxHcisZqP+j/Em+/1wJrXh0 ngZ/nfZWAWyX5FgiwklSV6BsQ0DD59NWDeFDh4bkZxUaTsy3OCXipnQc7VAHuM/rOR0G YtH1XK6tGryP+MygBDj9xsS05MtGiKNatWphnBjLeLOEAJ8EaDKYorndmL+ew0klTOW3 GRmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701343526; x=1701948326; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GDbsT3Sdr0VPEfLE4bfaBSqvIQva1DgTNiHkOioKC3M=; b=f9qGO4yWLzIiylcEQEip7o5CwjycqMlbEsEydXsxiiT0aSvDyEf6LsvWfzwJX/aF/5 o/2eFQQ18Lgnqm83hhDN2251jeL/42WEsoQJzc9V8gkEAH0Oxt3TZCzAhEaic+hrbDcD R6WV7OyUpwG9Vi0ITltPyayOcdYnxGhVOdeF/APf1gV8ZoEXFrxxK1sD161ILW9ipouL mEJvO743fcngwlFwXiZfbx5G34ulAGTrTnERrjWMI+DeMS/YaMssL7c8RXgRvzT7CkdZ 2A8xVwqvVN1GA3ZWyigiiEyaR4x15zu5zRq0c9OeEOYygpYzFdTsqIkp40K1Z+u9SZXe odGA== X-Gm-Message-State: AOJu0YyCr/v6RP8LEAsq/i6ihAhR1jPB27Y6vwSEZt2GwJqUovKpOUES RCO7gMAwD4PhIZyAN1B+BZoE2nZPmsgf/bJp+EXMCMexwdjLJNwHdeg= X-Google-Smtp-Source: AGHT+IEF88Ycby9oZGuOUFuJv0mwN7wMLiq3KMS/NYPqvn97IOt3reZDSMW55mQl919XOWvMWyKWNXvi0VnNzT9Kojw= X-Received: by 2002:a17:90b:33d1:b0:285:dc80:e207 with SMTP id lk17-20020a17090b33d100b00285dc80e207mr10549144pjb.49.1701343526175; Thu, 30 Nov 2023 03:25:26 -0800 (PST) MIME-Version: 1.0 From: Edwin Brossette Date: Thu, 30 Nov 2023 12:25:15 +0100 Message-ID: Subject: net/e1000: Test issues following change in max rx/tx queues To: dev@dpdk.org Cc: Olivier Matz , Laurent Hardy Content-Type: multipart/alternative; boundary="00000000000084dcf4060b5ce8a4" 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 --00000000000084dcf4060b5ce8a4 Content-Type: text/plain; charset="UTF-8" Hello, We recently started to observe concerning behaviour on our continuous integration platform following this commit, which set the maximum amount of tx/rx queues at 2 for the e1000 pmd: net/e1000: fix queue number initialization https://git.dpdk.org/dpdk/commit/?id=c1a42d646472fd3477429bf016f682e0865b77f0 Reverting this change locally on our side was enough to fix our test issues. There is a considerately long explanation in a comment just above the change explaining why the number of rx/tx queues is limited at 1, yet it was changed at 2 anyway. Since I couldn't see any mention in logs about theses restrictions being removed, I wished to inquire whether this change was truly intended and if there was any problem which motivated it. Maybe the max number of rx/tx queues should reverted back to 1? Or maybe the comment should be updated if limitations are no longer true? Regards, Edwin Brossette. --00000000000084dcf4060b5ce8a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

We recently star= ted to observe concerning behaviour on our continuous integration platform=C2=A0 followin= g=20 this commit, which set the maximum amount of tx/rx queues at 2 for the=20 e1000 pmd:

net/e1000: fix queue number initializat= ion

Reverting this change locally on our side was enough to fix our tes= t issues.

There is a considerately long explanation in a comment just above the change=20 explaining why the number of rx/tx queues is limited at 1, yet it was=20 changed at 2 anyway.

Since I couldn't see= =20 any mention in logs about theses restrictions being removed, I wished to inquire whether this change was truly intended and if there was any proble= m which motivated it.
Maybe the max number of rx/tx queues should reverted back to 1? Or maybe the comment=20 should be updated if limitations are no longer true?

Regards,
Edwin Brossette.
--00000000000084dcf4060b5ce8a4--