netdev - RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support

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]

Date:	Tue, 16 Aug 2011 19:14:01 -0700
From:	Rasesh Mody <rmody@...cade.com>
To:	John Fastabend <john.r.fastabend@...el.com>,
	Ben Hutchings <bhutchings@...arflare.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Adapter Linux Open SRC Team 
	<adapter_linux_open_src_team@...cade.COM>,
	Gurunatha Karaje <gkaraje@...cade.com>
Subject: RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support

>From: John Fastabend [mailto:john.r.fastabend@...el.com]
>Sent: Tuesday, August 16, 2011 5:18 PM
>
>On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>
>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>> Change details:
>>>>>  - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>>    bna_is_iscsi_over_cee
>>>>>  - Added support for multipe Tx queues with a separate iSCSI Tx
>queue
>>>> based
>>>>>    on the default value of iSCSI port number. The feature is
>supported
>>>> based
>>>>>    on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>>  - Allocate multiple TxQ resource in netdev
>>>>>  - Implement bnad_tx_select_queue() which enables the correct
>>>> selection of
>>>>>    TxQ Id (and tcb). This function is called either by the kernel
>to
>>>> channel
>>>>>    packets to the right TxQ
>>>>>  - bnad_tx_select_queue() returns priority, while only a few
>packets
>>>> during
>>>>>    transition could have wrong priority, all will be associated
>with a
>>>> valid
>>>>>    non-NULL tcb.
>>>>>  - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>> packet
>>>>>    inspection and retrieval of tcb corresponding to the iSCSI
>>>> priority.
>>>>>  - Construction of priority indirection table to be used by bnad to
>>>> direct
>>>>>    packets into TxQs
>>>> [...]
>>>>
>>>> You probably should implement TX priority classes through the
>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>
>>> The reason we went with ndo_select_queue is due to the need for
>mapping
>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>configuration.
>>> Here the iSCSI packets may not have any tc defined in the packet
>header.
>>
>> There is an skb priority, which is derived from the socket priority
>> option (SO_PRIORITY).  If you implement ndo_setup_tc then the
>networking
>> core will take care of mapping the skb priority onto a different queue
>> (or range of queues).
>>
>> I don't know whether the socket priority option is easily configurable
>> for the existing iSCSI implementations.  But looking at port numbers
>> really doesn't seem like the right way to do this.
>>
>> Ben.
>>
>
>At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>events.
>These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>support
>this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>to
>add the application data and follow this with the appropriate notify
>call.
>Then assuming you do the necessary tc setup work the stack will handle
>the
>mapping of priority to queues.

This is how iSCSI over DCB feature is expected to works in BNA driver:-
FW running in the BNA adapter implements the DCB protocol. It learns the
iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
extracts the iSCSI priority from the FW that needs to be used for iSCSI
packets. For every outgoing packet, BNA driver does a TCP header
inspection to classify iSCSI packet and attach right 802.1q priority &
send it on the correct TX queue.

This is expected to work with iSCSI applications that do not configure the
priority with SO_PRIORITY - here the iSCSI priority configuration actually
comes from the switch to the adapter.

The goal of this iSCSI priority is:
a) adapter applies prioritized scheduling for packets in its egress - to
guarantee minimum bandwidth as per ETS
b) packets are tagged with right priority so that switch can also identify
and guarantee BW on its egress.

Hope this explains.

Thanks,
Rasesh