netdev - Re: [PATCH net-next 1/3] net/dcb: Add IEEE QCN attribute

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:	Thu, 05 Mar 2015 07:05:43 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Shachar Raindel <raindel@...lanox.com>
CC:	Or Gerlitz <gerlitz.or@...il.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>,
	John Fastabend <john.r.fastabend@...el.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Amir Vadai <amirv@...lanox.com>, Tal Alon <talal@...lanox.com>,
	Shani Michaeli <shanim@...lanox.com>
Subject: Re: [PATCH net-next 1/3] net/dcb: Add IEEE QCN attribute

[...]

>>
>>> Looks good to me. Do you have a QCN enabled switch? I looked at
>>> implementing this awhile ago but didn't have any switch support so
>>> I never did it.
>>
>> I'l let Shachar to address the testing and the MIB questions.
>
> The Mellanox SwitchX-2 IC supports QCN. We were testing our NICs both
> with this switch IC and using internal test fixtures where we were
> injecting congestion notification messages as raw Ethernet packets by
> another host.

ah great didn't know that switch supported QCN.

>
>>
>>> Also do you have a user space client to configure this? I would like
>>> it if someone wanted to add support to lldpad/dcbtool.
>>
>> Sure, we have some netlink (python scripts) code to configure/read
>> this towards the kernel.
>>
>>
>>> [...]

[...]

>>>
>>>
>>> I'm assuming this structure maps to an IEEE MIB?
>>
>> yep, I guess so
>
> The structures map to the IEEE MIB for QCN (part of IEEE 802.1Qau).
> The fields rppp_max_rps and cndd_state_machine are in different sections
> than the rest of the fields. However, it seems bit redundant to define a
> whole struct just for one field. The cndd_state_machine is not explicitly
> defined in the MIB, as the LLDP negotiation, which the standard assumes,
> is implemented by lldpad.
>
>>
>>> Its a rather large structure for a single netlink type but this seems
>>> to be how we built
>>> the dcbnl interface and if it does seem logical that the structure is
>>> one logical block, meaning you need to supply all fields.
>>
>
> This is the set of parameters defining how you will reduce or increase you
> TX rate upon receiving CNM from the network. I agree that it is a long list,
> but this is how the standard was written...

yep works for me. I was just checking my assumptions are correct and
admittedly being a bit lazy so I didn't pull up the spec myself.

Thanks,
John

[...]

-- 
John Fastabend         Intel Corporation
--
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