RE: [PATCH] NET: DCB generic netlink interface

From: "Waskiewicz Jr, Peter P" <redacted>
Date: Wed, 4 Jun 2008 23:23:00 -0700

quoted

I'm not sure I follow this.  DCB is a scheduling policy, but that 
scheduling policy is in the hardware.  The configuration interface, 
which is what this is, happens out of band of any 

scheduling policies 

quoted

in the kernel.  It's very analogous to the wireless configuration 
layer for
mac80211 that uses generic netlink.

And I'm saying we should have a equivalent software scheduler 
in the kernel that can implement this if the hardware 
offloaded version isn't present.

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.

This technology really is a hardware-based technology.  The piece that
we could effectively implement in software is the Tx priority grouping.
But that's a small piece of the whole technology.  All we're trying to
do is provide the method of configuring the hardware for this
technology, which is closely coupled with the FCoE work going on in the
SCSI world.  I don't think anyone would benefit trying to emulate it in
software, since everything we can implement in the software can already
be achieved using existing facilities.

It overlaps existing functionality to a certain extent, and 
there is no real reason for that overlap to exist.  The 
question is which (the existing facilities or the new one) 
subsumes which.

The existing facilities for traffic shaping and bandwidth aggregation do
overlap if you loaded those qdiscs with a DCB device.  But I don't think
the existing qdiscs should be removed or modified; the two technologies
are too different, in my opinion, to be combined in software.

Thanks Dave,
-PJ Waskiewicz