netdev - Re: [net-2.6 PATCH 1/2] net: dcbnl: remove redundant DCB_CAP_DCBX

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: <1295882871.25104.20.camel@lb-tlvb-shmulik.il.broadcom.com>
Date:	Mon, 24 Jan 2011 17:27:51 +0200
From:	"Shmulik Ravid" <shmulikr@...adcom.com>
To:	"John Fastabend" <john.r.fastabend@...el.com>
cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-2.6 PATCH 1/2] net: dcbnl: remove redundant
 DCB_CAP_DCBX_STATIC bit


On Sun, 2011-01-23 at 21:46 -0800, John Fastabend wrote:
> On 1/23/2011 8:53 AM, Shmulik Ravid wrote:
> > 
> > On Fri, 2011-01-21 at 18:52 -0800, John Fastabend wrote:
> >> On 1/21/2011 6:35 PM, John Fastabend wrote:
> >>> Remove redundant DCB_CAP_DCBX_STATIC bit in DCB capabilities
> >>>
> >>> Setting this bit indicates that no embedded DCBx engine is
> >>> present and the hardware can not be configured. This is the
> >>> same as having none of the DCB capability flags set or simply
> >>> not implementing the dcbnl ops at all.
> >>>
> >>> This patch removes this bit. The bit has not made a stable
> >>> release yet so removing it should not be an issue with
> >>> existing apps.
> >>>
> >>> Signed-off-by: John Fastabend <john.r.fastabend@...el.com>
> >>> CC: Shmulik Ravid <shmulikr@...adcom.com>
> >>> ---
> >>>
> >>
> >> Shmulik, could you ACK this because you added these bits? But
> >> I was adding support for this in lldpad and I see no reason that
> >> we need these?
> >>
> > DCB_CAP_DCBX_STATIC means that the embedded engine will turn the user
> > configuration into the operational configuration without performing the
> > actual negotiation, so it is not equivalent to not having an embedded
> > DCBx engine. This is mostly a debug and integration option as it allows
> > you to do DCB related or dependent testing and development without
> > having a proper DCBx peer.
> > 
> > On second thought, I'm not sure this option is justified although we
> > found it useful during our development. If you think it's not useful
> > enough (or not at all) then by all means remove it.
> 
> We have an advertise bit in userspace that can be set and cleared to
> do something similar for host based agents. I think for pg and application
> data you can get the same behavior by setting the device to not willing.
> 
True, but this requires a proper DCBx peer. The STATIC option is a bit
stronger.

> However for PFC it could potentially be useful. But how would the
> user set this mode? This is a capabilities bit indicating the device
> supports this. Is there a way to subsequently put the device in this
> mode?
You can set this mode by specifying this attribute in the set_dcbx
operation. The input to set_dcbx should be a subset of the advertised
dcbx attributes.

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