[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080605202953.GN20815@postel.suug.ch>
Date: Thu, 5 Jun 2008 22:29:53 +0200
From: Thomas Graf <tgraf@...g.ch>
To: David Miller <davem@...emloft.net>
Cc: peter.p.waskiewicz.jr@...el.com, jeff@...zik.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] NET: DCB generic netlink interface
* David Miller <davem@...emloft.net> 2008-06-05 07:43
> From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
> Date: Wed, 4 Jun 2008 23:23:00 -0700
>
> > 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 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 agree, I think we should make it possible to use DCB without the strict
need for hardware support. Our current classful qdiscs htb and cbq already
fullfil the requirements of priority grouping as specified in 802.1.qaz
except that the configuration interface is different as it does not use
percentage values.
There is also demand for a networking cgroup subsystem which requires
exactly the same kind of priority grouping. It would be only logical
to be able to use hardware support where possible.
Therefore I believe the way to go is to build a new or extend the
current tc system. Like with the current default qdisc, it should be
possible to automatically create qdiscs for DCB or cgroup while still
allowing to overwrite the tc configuration with a custom tree for
As Patrick pointed out, this probably belongs in the rtnetlink family as
it will be strictly attached to the net_device.
--
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