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]

Message-ID: <20080528223728.GF20815@postel.suug.ch>
Date:	Thu, 29 May 2008 00:37:28 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	jeff@...zik.org, davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH 1/3] [NET-NEXT]: Add DCB netlink interface definition

* Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@...el.com> 2008-05-28 09:03
> 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).

There isn't much difference really, instead of using the separate
interface you could simply add a new link attribute IFLA_DCB and issue
a RTM_SETLINK/RTM_GETLINK and send the same information in the same
format. However, I agree with you that a separate interface is better
in this case as dcb requests are not directly connected to other link
changes at all and the dcb message structure is pretty complex.

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

A prominent user is the VLAN code in net/8021q/vlan_netlink.c

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

Looks good from here, I didn't read it all line by line though.
--
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