netdev - Re: [PATCH net-next 1/3] dcbnl: adding DCBX engine capability

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: <1293631142.29378.22.camel@lb-tlvb-shmulik.il.broadcom.com>
Date:	Wed, 29 Dec 2010 15:59:02 +0200
From:	"Shmulik Ravid" <shmulikr@...adcom.com>
To:	"John Fastabend" <john.r.fastabend@...el.com>
cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"Eilon Greenstein" <eilong@...adcom.com>,
	"Liu, Lucy" <lucy.liu@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] dcbnl: adding DCBX engine capability

On Tue, 2010-12-28 at 16:05 -0800, John Fastabend wrote:

> I would like to use these bits for guests using a VF as well. The
>  problem is multiple lldp agents advertising dcbx tlvs on the same link
>  is not spec compliant. In the VF case there may or may not be a
>  hardware lldp engine all the VF driver (ie ixgbevf) should need to
>  know is that some other entity is managing the DCB attributes.
> 
> To reflect this I would propose changing DCB_CAP_DCBX_HW and the comments by removing "HW". The two ideas I had were DCB_CAP_DCBX_READONLY or DCB_CAP_DCBX_LLD_MANAGED. Admittedly a bit of a nitpick but its a bit confusing to set the DCBX_HW bit when there really is no HW engine in the 82599 adapter case.
> 
> Otherwise this all looks good to me. I was hoping someone would get around to this. Thanks a lot!
> 
> -- John.
> 

I see your point, I like DCB_CAP_DCBX_LLD_MANAGED better. I will change
it an resubmit the patches. DCB_CAP_DCBX_HW implies 3 things:
1. DCBX negotiation is managed by some other entity.
2. The user can use the 'get' routines to get the negotiation results.
3. The user can use the 'set' routines to set the initial configuration
for the negotiation. 
I think No 3. is irrelevant to VFs, that is you don't want multiple VF
drivers trying to change the initial configuration settings. I can think
of 2 ways to make this distinction, the first is for the VF driver not
to support the 'set' routines (or always return an error value). The
second is to add another attribute flag: DCB_CAP_DCBX_LLD_CFG which will
indicate exactly No 3. while DCB_CAP_DCBX_LLD_MANAGED will indicate No
1. and 2. The VF driver will declare DCB_CAP_DCBX_LLD_MANAGED only and a
driver for an embedded DCBX engine will declare both flags. What do you
think?

Thanks
Shmulik.

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