根据OSI参考模型来分，Qos可以应用在如下两层：即上层协议（主要是应用层）与链路层以及物理层网卡发出数据处。前者是通过TC工具对上层协议数据实施Qos，原理就是首先在应用层对要处理的包或者流打上mark，然后利用TC工具多不同的流量实施不同的功能处理，如流量整形，优先级设置，调度与过滤等等，值得说明的是TC工具实质是一套中间件，功能最后均由内核去负责实现；至于后者的Qos，就是在网卡驱动处设置Qos，具体实现与TC工具类似，最后也是由内核去负责实现。
一、上层协议Qos以及TC工具原理分析：
TC是一个在上层协议处添加Qos功能的工具，原理上看，它实质是专门供用户利用内核Qos调度模块去定制Qos的中间件，本节主要是阐述TC工具是如何去队列规则的，以及内部是如何实现的。
首先需要了解的是，TC作为一个应用工具，它又是如何与内核去实现通讯的？很简单，消息机制，所借助的工具则是Netlink，而所使用的协议正是NETLINK_ROUTE，更加详细的Netlink相关的知识，请参考《linux内核与用户之间的通信方式——虚拟文件系统、ioctl以及netlink》。不过在此可以说明下TC源代码中是如何初始化rtnetlink（可以理解为专门为路由设计的netlink）socket的。
struct rtnl_handle
{
int fd;
struct sockaddr_nl local;
struct sockaddr_nl peer;
__u32 seq;
__u32 dump;
};
struct rtnl_handle *rth
rth->fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
...
rth->local.nl_family = AF_NETLINK;
rth->local.nl_groups = 0;
bind(rth->fd, (struct sockaddr*)&rth->local, sizeof(rth->local);下面主要以TC工具对qdisc操作（包括增加，修改，取代等等）的实现。对qdisc规则解析代码是在tc_qdisc_modify函数中完成的，然后通过消息机制交给内核相关模块去处理。下面是其中一段消息初始化代码片段：
struct {
struct nlmsghdr n;
struct tcmsg t;
char buf[TCA_BUF_MAX];
} req;
struct tcmsg
{
unsigned char tcm_family;
unsigned char tcm__pad1;
unsigned short tcm__pad2;
int tcm_ifindex;
__u32 tcm_handle;
__u32 tcm_parent;
__u32 tcm_info;
};
req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg));
req.n.nlmsg_flags = NLM_F_REQUEST|flags;
req.n.nlmsg_type = RTM_NEWQDISC;
req.t.tcm_family = AF_UNSPEC;需要解释的是，tcmsg结构体定义了跟流量控制相关的消息内容，nlmsghdr则定义了消息头，消息头中附带了消息的类型以及标志量（主要用来区分各种不同的消息），常见的消息类型有（只是针对qdisc而言，若是class或者filter，肯定会有差别）：RTM_NEWQDISC和RTM_DELQDISC；常见的标志量有：NLM_F_REQUEST，NLM_F_CREATE，NLM_F_REPLACE，NLM_F_EXCL，分别意味着该消息时一个请求类的消息，进行创建或者取代操作，若存在则不予处理。Qdisc有关的各种操作所对应的消息类型以及标志量总结如下表：
有一点值得注意的是，因为针对各种不同的调度机制，有着不一样的参数选项，如sfq所对应的参数就有quantum， perturb, limit等，而htb则有r2q, default,在TC工具中针对这些不同的调度机制，定义了不一样的解析函数。如sfq和htb中的定义如下：
struct qdisc_util htb_qdisc_util = {
.id = "htb",
.parse_qopt = htb_parse_opt,
.print_qopt = htb_print_opt,
.print_xstats = htb_print_xstats,
.parse_copt = htb_parse_class_opt,
.print_copt = htb_print_opt,
};
struct qdisc_util sfq_qdisc_util = {
.id = "sfq",
.parse_qopt = sfq_parse_opt,
.print_qopt = sfq_print_opt,
}; q = get_qdisc_kind(k);
...
if (q->parse_qopt(q, argc, argv, &req.n))
return 1;
所有的参数均解析完成之后，接下来就是将消息发给内核（接着内核将会处理所收到的消息请求），并及时接受内核的回复消息。下面着重阐述内核在收到消息请求之后是如何进行处理的呢？首先需要明白的是，当内核接收到请求消息后，按照消息的什么内容去完成消息的处理呢？消息的类型！前面总结了tc工具在不同的规则下有着对应的消息类型，例如，add, change, replace等操作所对应的消息类型则是RTM_NEWQDISC，因此，内核在收到此种消息类型之后会调用相应的模块去进行处理。OK，这些消息处理模块全部放在了sch_api.c文件中，相关代码如下：
static int __init pktsched_init(void)
{
register_qdisc(&pfifo_qdisc_ops);
register_qdisc(&bfifo_qdisc_ops);
proc_net_fops_create(&init_net, "psched", 0, &psched_fops);
rtnl_register(PF_UNSPEC, RTM_NEWQDISC, tc_modify_qdisc, NULL);
rtnl_register(PF_UNSPEC, RTM_DELQDISC, tc_get_qdisc, NULL);
rtnl_register(PF_UNSPEC, RTM_GETQDISC, tc_get_qdisc, tc_dump_qdisc);
rtnl_register(PF_UNSPEC, RTM_NEWTCLASS, tc_ctl_tclass, NULL);
rtnl_register(PF_UNSPEC, RTM_DELTCLASS, tc_ctl_tclass, NULL);
rtnl_register(PF_UNSPEC, RTM_GETTCLASS, tc_ctl_tclass, tc_dump_tclass);
return 0;
}
从上面这段代码可以看出，模块中注册了消息类型以及与处理函数的对应关系。此处以RTM_NEWQDISC消息类型为例，此时需要调用tc_modify_qdisc函数去处理。处理的基本思想是这样的：因为不同的规则可能对应着相同的消息类型（如RTM_NEWQDISC），此时就需要再通过消息的标志量做进一步的操作，最后通过调用内核中有关qdisc的API函数去完成，相关代码片段如下：
static int tc_modify_qdisc(struct sk_buff *skb, struct nlmsghdr *n, void *arg)
{
......
err = nlmsg_parse(n, sizeof(*tcm), tca, TCA_MAX, NULL);
if (err < 0)
return err;
if (clid) {
.......
if (!q || !tcm->tcm_handle || q->handle != tcm->tcm_handle) {
if (tcm->tcm_handle) {
......
if ((q = qdisc_lookup(dev, tcm->tcm_handle)) == NULL)
goto create_n_graft;
......
atomic_inc(&q->refcnt);
goto graft;
} else {
if (q == NULL)
goto create_n_graft;
if ((n->nlmsg_flags&NLM_F_CREATE) &&
(n->nlmsg_flags&NLM_F_REPLACE) &&
((n->nlmsg_flags&NLM_F_EXCL) ||
(tca[TCA_KIND] &&
nla_strcmp(tca[TCA_KIND], q->ops->id))))
goto create_n_graft;
}
}
......
/* Change qdisc parameters */
......
err = qdisc_change(q, tca);
if (err == 0)
qdisc_notify(skb, n, clid, NULL, q);
return err;
create_n_graft:
if (!(n->nlmsg_flags&NLM_F_CREATE))
return -ENOENT;
if (clid == TC_H_INGRESS)
q = qdisc_create(dev, &dev->rx_queue,
tcm->tcm_parent, tcm->tcm_parent,
tca, &err);
else
q = qdisc_create(dev, netdev_get_tx_queue(dev, 0),
tcm->tcm_parent, tcm->tcm_handle,
tca, &err);
......
graft:
err = qdisc_graft(dev, p, skb, n, clid, q, NULL);
......
return 0;
}
从上面的片段中可以看出，根据不同的标志量，调用不同的API函数去完成最后的功能，如qdisc_change用于去修改原qdisc规则，修改完成之后然后调用qdisc_notify去回复响应TC，qdisc_create用于去重新创建一个新的qdisc队列规则，qdisc_graft函数用于去将qdisc移植到某个对象上去。
以上以TC工具对Qdisc操作为例简单地阐述了TC工具是如何与内核进行交互的，以及内核又是如何响应请求并作出处理的，下节将探讨在ATM设备上如何设置Qos。
二、ATM设备的Qos：
本节结合Broadcom代码分析ATM设备上的Qos是如何被设置的。在讨论此问题之前，需要明白ATM设备是如何创建的，当用户配置通过ADSL拨号方式上网时，此时将会生成一个ATM设备接口，具体的创建过程代码片段如下：
static int bcmxtmcfg_ioctl( struct inode *inode, struct file *flip,unsigned int command, unsigned long arg )
{
int ret = 0;
unsigned int cmdnr = _IOC_NR(command);
FN_IOCTL IoctlFuncs[] = {DoInitialize, DoUninitialize, DoGetTrafficDescrTable, DoSetTrafficDescrTable, DoGetInterfaceCfg,
DoSetInterfaceCfg, DoGetConnCfg, DoSetConnCfg, DoGetConnAddrs,
DoGetInterfaceStatistics, DoSetInterfaceLinkInfo, DoSendOamCell,
DoCreateNetworkDevice, DoDeleteNetworkDevice, DoReInitialize, DoGetBondingInfo, NULL};
if( cmdnr >= 0 && cmdnr < MAX_XTMCFGDRV_IOCTL_COMMANDS &&
IoctlFuncs[cmdnr] != NULL )
{
(*IoctlFuncs[cmdnr]) (arg);
}
……
}
Bcmxtmcfg_ioctl在收到来自于用户请求需要创建一个XTM（ATM或者PTM）时，接着调用DoCreateNetworkDevice函数，最后向bcmxtmrt驱动发送创建设备的请求信息XTMRT_CMD_CREATE_DEVICE，相关代码片段如下：
int bcmxtmrt_request( XTMRT_HANDLE hDev, UINT32 ulCommand, void *pParm )
{
PBCMXTMRT_DEV_CONTEXT pDevCtx = (PBCMXTMRT_DEV_CONTEXT) hDev;
int nRet = 0;
switch( ulCommand )
{
.......
case XTMRT_CMD_CREATE_DEVICE:
nRet = DoCreateDeviceReq( (PXTMRT_CREATE_NETWORK_DEVICE) pParm );
break;
.......
}
接着进入DoCreateDeviceReq接口函数去创建设备，相关代码片段如下：
static int DoCreateDeviceReq( PXTMRT_CREATE_NETWORK_DEVICE pCnd )
{
......
if( pGi->ulDrvState != XTMRT_UNINITIALIZED &&
(dev = alloc_netdev( sizeof(BCMXTMRT_DEV_CONTEXT),
pCnd->szNetworkDeviceName, ether_setup )) != NULL )
{
dev_alloc_name(dev, dev->name);
SET_MODULE_OWNER(dev);
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30)
pDevCtx = (PBCMXTMRT_DEV_CONTEXT) netdev_priv(dev);
#else
pDevCtx = (PBCMXTMRT_DEV_CONTEXT) dev->priv;
#endif
memset(pDevCtx, 0x00, sizeof(BCMXTMRT_DEV_CONTEXT));
memcpy(&pDevCtx->Addr, &pCnd->ConnAddr, sizeof(XTM_ADDR));
if(( pCnd->ConnAddr.ulTrafficType & TRAFFIC_TYPE_ATM_MASK ) == TRAFFIC_TYPE_ATM )
pDevCtx->ulHdrType = pCnd->ulHeaderType;
else
pDevCtx->ulHdrType = HT_PTM;
if (pDevCtx->ulHdrType == HT_PTM) {
if (pGi->bondConfig.sConfig.ptmBond == BC_PTM_BONDING_ENABLE)
pDevCtx->ulTrafficType = TRAFFIC_TYPE_PTM_BONDED ;
else
pDevCtx->ulTrafficType = TRAFFIC_TYPE_PTM ;
}
else {
if (pGi->bondConfig.sConfig.atmBond == BC_ATM_BONDING_ENABLE)
pDevCtx->ulTrafficType = TRAFFIC_TYPE_ATM_BONDED ;
else
pDevCtx->ulTrafficType = TRAFFIC_TYPE_ATM ;
}
......
/* format the mac id */
i = strcspn(dev->name, "0123456789");
if (i > 0)
unit = simple_strtoul(&(dev->name[i]), (char **)NULL, 10);
if (pDevCtx->ulHdrType == HT_PTM)
macId = MAC_ADDRESS_PTM;
else
macId = MAC_ADDRESS_ATM;
/* set unit number to bit 20-27 */
macId |= ((unit & 0xff) << 20);
kerSysGetMacAddress(dev->dev_addr, macId);
......
dev->netdev_ops = &bcmXtmRt_netdevops; //控制接口（包括设备相关的ioctl函数）
#else
/* Setup the callback functions. */
dev->open = bcmxtmrt_open;
dev->stop = bcmxtmrt_close;
dev->hard_start_xmit = (HardStartXmitFuncP) bcmxtmrt_xmit;
dev->tx_timeout = bcmxtmrt_timeout;
dev->set_multicast_list = NULL;
dev->do_ioctl = &bcmxtmrt_ioctl;
dev->poll = bcmxtmrt_poll;
dev->weight = 64;
dev->get_stats = bcmxtmrt_query;
#endif
#if defined(CONFIG_MIPS_BRCM) && defined(CONFIG_BLOG)
dev->clr_stats = bcmxtmrt_clrStats;
#endif
dev->watchdog_timeo = SAR_TIMEOUT;
/* identify as a WAN interface to block WAN-WAN traffic */
dev->priv_flags |= IFF_WANDEV;
switch( pDevCtx->ulHdrType )
{
......
nRet = register_netdev(dev);
........
}
void dev_init_scheduler(struct net_device *dev)
{
netdev_for_each_tx_queue(dev, dev_init_scheduler_queue, &noop_qdisc);
dev_init_scheduler_queue(dev, &dev->rx_queue, &noop_qdisc);
setup_timer(&dev->watchdog_timer, dev_watchdog, (unsigned long)dev);
}
从代码中可以看到初始化时给设备加载的是noop_qdisc规则，而通过此规则对应的回调函数可以看出，实质上他并没有给队列加载任何规则，只是做了释放空间的工作。以noop_enquene为例，它负责对入队列加载规则，但是在noop_enqueue函数仅仅进行了数据的释放。
struct Qdisc noop_qdisc = {
.enqueue = noop_enqueue,
.dequeue = noop_dequeue,
.flags = TCQ_F_BUILTIN,
.ops = &noop_qdisc_ops,
.list = LIST_HEAD_INIT(noop_qdisc.list),
.q.lock = __SPIN_LOCK_UNLOCKED(noop_qdisc.q.lock),
.dev_queue = &noop_netdev_queue,
};
static int noop_enqueue(struct sk_buff *skb, struct Qdisc * qdisc)
{
kfree_skb(skb);
return NET_XMIT_CN;
}
OK，前面很长篇幅阐述了broadcom代码中是如何去生成一个XTM设备以及是如何去完成它的初始化的，同时也知道了对新创建的设备并没有加载任何的Qos规则，那么要想对刚创建的设备增加Qos功能，该如何去实现呢？首先在rutQos_qMgmtQueueConfig函数中完成了对QMgmtQueueObject对象的相关Qos参数的设置，之后调用devCtl_xtmSetConnCfg函数试图将所配置的参数写进ATM设备中，之后进入bcmxtmcfg_ioctl中的DoSetConnCfg函数，然后是BcmXtm_SetConnCfg函数，一次类推，最后是通过DoSetTxQueue函数完成最后的配置，整个逻辑流程如下：
ATM TC:
Rut_qos.c(rutQos_qMgmtQueueConfig-->devCtl_xtmSetConnCfg)bcmxtmcfg_ioctl-->DoSetConnCfg-->BcmXtm_SetConnCfg-->SetConnCfg-->SetCfg->CheckTransmitQueues->bcmxtmrt_request-àDoSetTxQueue
参考文献：
1 Linux 2.4.x 网络协议栈QoS模块(TC)的设计与实现（http://www.ibm.com/developerworks/cn/linux/kernel/l-qos/）
2375
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
