lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160107154324.4081743c@jkicinski-Precision-T1700>
Date:	Thu, 7 Jan 2016 15:43:24 +0000
From:	Jakub Kicinski <jakub.kicinski@...ronome.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:	David Miller <davem@...emloft.net>,
	Michael Chan <mchan@...adcom.com>,
	Prashant Sreedharan <prashant@...adcom.com>,
	Amit Kumar Salecha <amit.salecha@...gic.com>,
	Ben Hutchings <ben@...adent.org.uk>
Subject: Question regarding {G,S}CHANNELS API

Hi!

I'm trying to understand how number of "separate" rx/tx vs combined
channels should be configured.  I'd like to express asymmetric but
mostly combined queue configuration (i.e. min(rx, tx) is combined the
rest is separate).  Since default number of RX queues is just 8 it is
tempting to allocate 8 RX queues but num_online_cpus() TX queues.  Does
this configuration make sense?  What should ethtool -l report?

I had a look through the drivers and it seems that most of them fall
nicely into the all combined and all separate categories. Two
exceptions I found are bnxt_en (recent Michael's changes) and tg3.
bnxt_en can switch between combined and separate mode.  tg3 is more
interesting, it uses separate rx/tx parameters but combines first
min(rx, tx) of the queues as I would like to.

The problem is if I hijack the "separate" rx/tx queues parameters like
tg3 does there is no way for the user to express that (s)he truly wants
them separate.  Also it seems that tg3 goes against the ethtool manual
which states:
>  rx N   Changes the number of channels with only receive queues.
>  tx N   Changes the number of channels with only transmit queues.
Which indicates that if user wants 8 rx, 12 tx and combining (s)he
should do:
  ethtool -L ethX combined 8 tx 4

This, however, makes the max_* info from SCHANNLES quite imprecise
since device which has 16 IRQs and 16 queues in each directions would
probably report:
max_rx:       16
max_tx:       16
max_combined: 16
But setting 'ethtool -L ethX combined 16 tx 8' would obviously
fail even though parameters are within 1..max limits.

Any comments/advice would be much appreciated.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ