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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <A31CB8AA22AA1E44B81563BEDB2C187812203E1118@SJEXCHCCR01.corp.ad.broadcom.com>
Date:	Fri, 25 Feb 2011 01:58:08 -0800
From:	"Shmulik Ravid - Rabinovitz" <shmulikr@...adcom.com>
To:	"John Fastabend" <john.r.fastabend@...el.com>
cc:	"davem@...emloft.net" <davem@...emloft.net>,
	"Eilon Greenstein" <eilong@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
 peer configuration - ieee

> -----Original Message-----
> From: John Fastabend [mailto:john.r.fastabend@...el.com]
> Sent: Friday, February 25, 2011 6:58 AM
> To: Shmulik Ravid - Rabinovitz
> Cc: davem@...emloft.net; Eilon Greenstein; netdev@...r.kernel.org
> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
> peer configuration - ieee
> 
> On 2/24/2011 2:03 PM, Shmulik Ravid - Rabinovitz wrote:
> >> -----Original Message-----
> >> From: John Fastabend [mailto:john.r.fastabend@...el.com]
> >> Sent: Thursday, February 24, 2011 10:37 PM
> >> To: Shmulik Ravid - Rabinovitz
> >> Cc: davem@...emloft.net; Eilon Greenstein; netdev@...r.kernel.org
> >> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for
> retrieving
> >> peer configuration - ieee
> >>
> >> On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
> >>> These 2 patches add the support for retrieving the remote or peer
> >> DCBX
> >>> configuration via dcbnl for embedded DCBX stacks. The peer
> >> configuration
> >>> is part of the DCBX MIB and is useful for debugging and diagnostics
> >> of
> >>> the overall DCB configuration. The first patch add this support for
> >> IEEE
> >>> 802.1Qaz standard the second patch add the same support for the
> older
> >>> CEE standard.
> >>>
> >>> Signed-off-by: Shmulik Ravid <shmulikr@...adcom.com>
> >>> ---
> >>>  include/linux/dcbnl.h |   38 ++++++++++++++++++++++++++
> >>>  include/net/dcbnl.h   |    5 +++
> >>>  net/dcb/dcbnl.c       |   71
> >> +++++++++++++++++++++++++++++++++++++++++++++++++
> >>>  3 files changed, 114 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> >>> index 4c5b26e..3102185 100644
> >>> --- a/include/linux/dcbnl.h
> >>> +++ b/include/linux/dcbnl.h
> >>> @@ -110,6 +110,22 @@ struct dcb_app {
> >>>  	__u16	protocol;
> >>>  };
> >>>
> >>> +/* This structure contains the APP feature information sent by the
> >> peer.
> >>> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> >>> + *
> >>> + * @willing: willing bit in the peer APP tlv
> >>> + * @error: error bit in the peer APP tlv
> >>> + * @app_count: The number of objects in the peer APP table.
> >>> + *
> >>> + * In addition to this information the full peer APP tlv also
> >> contains
> >>> + * a table of 'app_count' APP objects defined above.
> >>> + */
> >>> +struct dcb_peer_app_info {
> >>> +	__u8	willing;
> >>> +	__u8	error;
> >>> +	__u16	app_count;
> >>> +};
> >>> +
> >>
> >> The IEEE 802.1Qaz spec defines the APP TLV as informational
> >> so there are no willing or error bits in this case. See
> >> section D.2.12 of the 802.1Qaz draft.
> >>
> >> Can we drop these fields or do they have some other meaning
> >> here?
> >>
> > OK, They are part of the CEE APP tlv though.
> > I wanted to share this structure between the 802.1Qaz and CEE so
> > I'll have a single driver handler that retrieve the number of
> > peer apps. How about if we keep a single driver handler, but the
> > APP info will be exposed to the user only with the CEE flavor.
> > That is the PEER_APP attribute will be CEE specific ?
> >
> > Shmulik
> >
> 
> That seems fine to me. Either don't expose the struct as you
> suggested or zero the fields while in IEEE mode.

I'll repost the patches making the app_info a CEE specific
attribute, I'll also eliminate the app_count from the user
interface because actually it's superfluous.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ