netdev - Re: [PATCH] NET: DCB generic netlink interface

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: <20080611175156.GR20815@postel.suug.ch>
Date:	Wed, 11 Jun 2008 19:51:56 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] NET: DCB generic netlink interface

* Waskiewicz Jr, Peter P <peter.p.waskiewicz.jr@...el.com> 2008-06-10 12:55
> I really don't think this is something that would work in software.  I
> agree that having a bandwidth grouping like 802.1Qaz would be somewhat
> useful, but that's the only piece of DCB that would work in software.
> And you can achieve the same behavior using sch_prio with cbq or htb on
> the nodes, minus the full link aggregation.
> 
> The 802.1Qbb, per-priority pause (flow control), cannot work in a
> software implementation.  This is a new flow control frame processed by
> the MAC for each priority on the link.  Also, the Rx filtering can't be
> emulated in software either.  The MAC filters on VLAN priority.  I know
> that can be configured with vconfig and set_ingress_map, but the whole
> point of the technology is to have the Rx processing done in the
> hardware's packet buffers, much like RSS filtering.

Everything is possible in software as long as the hardware doesn't hide
the congestion information. It would be very useful to pass congestion
information received by 802.1Qau frames to the kernel for use when
selecting the nexthop or for the routing daemon to make decisions on.
So far we could only react to link states, now we could actually react to
link congestion on the routing layer.

There is no doubt that doing the prioritization in hardware is much
preferred but we should try and integrate it with other tc techniques.
F.e. it would be great if we could control DCB via skb->tc_index if 
that is possible. It would allow to define DCB traffic classes with the
rich features of existing classifiers. I've seen there is a mapping
functionality although I haven't found any documentation on how to use
it exactly.

Another area of interest is sending congestion frames on our own. We
could finally implement real ingress software shaping and turn every
linux system into a DCB capable node.
--
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