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

Message-ID: <BEEA5B09-0726-463D-B542-234C4FB49FC5@qlogic.com>
Date:	Fri, 1 Apr 2011 22:47:01 -0700
From:	Anirban Chakraborty <anirban.chakraborty@...gic.com>
To:	Ben Hutchings <bhutchings@...arflare.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 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.

-Anirban

This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.

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