netdev - Re: [PATCH] net: ethtool support to configure number of channels

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-prev] [day] [month] [year] [list]

Date:	Wed, 06 Apr 2011 23:18:08 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Anirban Chakraborty <anirban.chakraborty@...gic.com>
Cc:	Amit Salecha <amit.salecha@...gic.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Ameen Rahman <ameen.rahman@...gic.com>,
	Sucheta Chakraborty <sucheta.chakraborty@...gic.com>
Subject: Re: [PATCH] net: ethtool support to configure number of channels

On Fri, 2011-04-01 at 22:47 -0700, Anirban Chakraborty wrote:
> On Apr 1, 2011, at 7:55 PM, Ben Hutchings wrote:
> 
> > On Fri, 2011-04-01 at 21:36 -0500, Amit Salecha wrote:
> >>> I'm not sure why you reduced this to a single count.  If if the driver
> >>> or hardware doesn't allow certain combinations of counts, it might be
> >>> necessary to configure several types at the same time
> >>>
> >>>> +/* Channel ID is made up of a type */
> >>>> +enum ethtool_channel_id {
> >>>> +   ETH_CHAN_TYPE_RX = 0x1,
> >>>> +   ETH_CHAN_TYPE_TX = 0x2
> >>>> +};
> >>> [...]
> >>>
> >>> enum ethtool_channel_id was meant to be an identifier of a specific
> >>> channel.  An enumeration of channel types should be named differently.
> >>>
> >>
> >> I will name it as ethtool_channel_type. Any other suggestion ?
> >>
> >>> This also omits the 'combined' and 'other' types.  Most multiqueue
> >>> drivers pair up RX and TX queues so that most channels combine RX and
> >>> TX
> >>> work.
> >>
> >> 'combined' is ok, what is use of 'other' ?
> >
> > Could be link interrupts, SR-IOV coordination, or something else.  Not
> > something you'd likely be able to change, but it could be useful to know
> > that some interrupts are allocated to them.  Actually, that does mean it
> > might be helpful for the 'get' operation to return a minimum value along
> > with the maximum value.
> 
> Are you thinking of using the 'other' field as a way to a represent a 'virtual port'
> that a VF could have. A virtual port could have a set of rx/tx rings, interrupts,
> QoS parameters, MAC filters, VLAN ids etc. etc. A VF could have one or many such
> channels. If thats the case, I would think that configuring these channels should
> be done via a PF rather than on a VF. It is possible I could get you totally wrong here,
> however it would be good to hear your thoughts.

The net device for a VF could have all sorts of channels, and their
numbers may or may not be configurable depending on limitations of the
hardware, firmware, driver or hypervisor.

The channel counts reported by a net device should include all those
IRQs allocated by the net device driver for its parent device (e.g. a
PCI device).

To be more concrete, here is how I would count channels:

1. RX queue with IRQ, exposed to the network stack => RX channel
2. TX queue with IRQ, exposed to the network stack => TX channel
3. RX and TX queue sharing IRQ, exposed to the network stack => combined channel
4. Link change IRQ => other channel
5. Queue(s) and IRQ for iSCSI traffic, not exposed to the network stack => other channel
6. Qeuue(s) and IRQ for coordination between PCI functions => other channel
7. Queue(s) and IRQ allocated to other PCI function => not counted

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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