netdev - RE: [PATCH 1/3] [NET-NEXT]: Add DCB netlink interface definition

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:	Wed, 28 May 2008 09:03:57 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Thomas Graf" <tgraf@...g.ch>
Cc:	<jeff@...zik.org>, <davem@...emloft.net>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 1/3] [NET-NEXT]: Add DCB netlink interface definition

> Is there a specific reason why you used a separate generic 
> netlink interface instead of embedding this into the regular 
> link message via either IFLA_DCB or by using the info API?

There are four reasons we decided to use a separate interface:

1. The netlink messages are generated via userspace when the connection
is setup, plus they're generated from LLDP frames coming in off the
wire.  Those LLDP frames implement the DCBX protocol (Data Center
Bridging Exchange), which is the negotiation protocol between a DCB
device and its link partner.  In most cases, it's a DCB-compliant
switch, like a Cisco Nexus 5000.  So the messages can come out of band
depending on how the network gets configured, and if any events occur
causing the bandwidth credits or priority mappings to change (think
automated backups at night, wanting more bandwidth than during the day).

2. The DCBX protocol is being extended to contain more information, and
second generation DCB devices have more configuration data for the
network.  So we wanted an interface that could be extended on its own to
support the new DCB protocols as they're ratified and implemented in new
equipment, without impacting existing infrastructure.

3. We wanted to use generic netlink, since that seems to be a more
preferred method of netlink communication vs. rtnetlink.  And I don't
know anything about the info API, so I can't comment on why we didn't
look at that for implementation.  Can you suggest something for me to
look at for the info API so I can see what that's all about?

4. We also developed the userspace utilities for the Linux OSVs, which
should be having a pre-release "release" on Sourceforge in the next week
or so, to support the DCBX protocol.  They're implemented using the
generic netlink interface, so obviously if we can keep it that way, it'd
be preferred.  :-)

Thanks Thomas.  Other than that, is there anything in the netlink
interface that you would suggest to change?

Cheers,
-PJ Waskiewicz
--
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