Changeset View
Standalone View
sys/netgraph/qos.h
- This file was added.
/*- | |||||
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD | |||||
* | |||||
* Copyright (c) 2019 Lutz Donnerhacke <lutz@donnerhacke.de> | |||||
* | |||||
* Redistribution and use in source and binary forms, with or without | |||||
* modification, are permitted provided that the following conditions | |||||
* are met: | |||||
* 1. Redistributions of source code must retain the above copyright | |||||
* notice, this list of conditions and the following disclaimer. | |||||
* 2. Redistributions in binary form must reproduce the above copyright | |||||
* notice, this list of conditions and the following disclaimer in the | |||||
* documentation and/or other materials provided with the distribution. | |||||
* | |||||
* THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND | |||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |||||
* ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE | |||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL | |||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS | |||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | |||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT | |||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | |||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF | |||||
* SUCH DAMAGE. | |||||
* | |||||
* $FreeBSD$ | |||||
*/ | |||||
#ifndef _NETGRAPH_QOS_H_ | |||||
#define _NETGRAPH_QOS_H_ | |||||
#include <sys/mbuf.h> | |||||
/* ABI cookie */ | |||||
#define M_QOS_COOKIE 1571268051 | |||||
#define MTAG_SIZE(X) ( sizeof(struct X) - sizeof(struct m_tag) ) | |||||
/* | |||||
* Definition of types within this ABI: | |||||
* - Choose a type (16bit) by i.e. "echo $((1000+$(date +%s)%64536))" | |||||
* - Retry if the type is already in use | |||||
* - Define the structure for the type according to mbuf_tags(9) | |||||
* struct m_qos_foo { | |||||
* struct m_tag tag; | |||||
* ... | |||||
* }; | |||||
* Preferred usage: | |||||
melifaro: Handling qos properly is something that has a lot of room for improvement in the networking… | |||||
Done Inline ActionsExtensiblity. Each time, a change to a given field in a complex tag needs to be made, all the ABI cookies need to change, Having multiple cookies for different tasks, simplifies the development and operational handing considerably. Mbuf_tags are handled by operators using ng_tag scripts. So changing the ABI requires to change the cookie and in consequence the scripts on production machines. I'd like to avoid as much of this trouble to operators. Regarding the memory size, Yes, that's a valid argument. Could it be solved by introducing a mbuf_tag_bitvalues type which collects as much as single bit values into a globally managed "flag" tag? In most cases there is no difference in memory overhead, because a packet will have only one or two tags attached. donner: Extensiblity. Each time, a change to a given field in a complex tag needs to be made, all the… | |||||
* struct m_qos_foo *p = (void *)m_tag_locate(m, | |||||
* M_QOS_COOKIE, M_QOS_FOO, ...); | |||||
* or | |||||
* p = (void *)m_tag_alloc( | |||||
* M_QOS_COOKIE, M_QOS_FOO, MTAG_SIZE(foo), ...); | |||||
m_tag_prepend(m, &p->tag); | |||||
*/ | |||||
/* Color marking type */ | |||||
#define M_QOS_COLOR 23568 | |||||
/* Keep colors ordered semantically in order to allow use of "<=" or ">=" */ | |||||
enum qos_color { | |||||
QOS_COLOR_GREEN, | |||||
QOS_COLOR_YELLOW, | |||||
QOS_COLOR_RED | |||||
}; | |||||
struct m_qos_color { | |||||
struct m_tag tag; | |||||
enum qos_color color; | |||||
}; | |||||
/* | |||||
* Priority class | |||||
* | |||||
* Processing per priority requires an overhead, which should | |||||
* be static (i.e. for alloctating queues) and small (for memory) | |||||
* So keep your chosen range limited. | |||||
*/ | |||||
#define M_QOS_PRIORITY 28858 | |||||
struct m_qos_priority { | |||||
struct m_tag tag; | |||||
uint8_t priority; /* 0 - lowest */ | |||||
}; | |||||
#endif /* _NETGRAPH_QOS_H_ */ | |||||
Done Inline ActionsAny reason to limit the value to 3 bits given DSCP values are 6 bits? melifaro: Any reason to limit the value to 3 bits given DSCP values are 6 bits? | |||||
Done Inline ActionsTypical hardware has a very limited number of QoS queues, so DCSP or similar are mapped to such a limited number of QoS profiles. In netgraph networks, queues are implemented by ng_tag switches to different paths, which is a cumbersome task. Tagging traffic on typically hardware (i.e. Cisco) has much more values than DCSP can express, so an other mapping is needed. OTOH practical DCSP values on interconnects are limited as they reflect the TOS bits. But the real reason is, that priority is a field from 802.1p where most hardware QoS is done. I have no problem in increasing this value and handle the details to the script maintainer of the production environment. donner: Typical hardware has a very limited number of QoS queues, so DCSP or similar are mapped to such… |
Handling qos properly is something that has a lot of room for improvement in the networking stack.
Struct m_tag is 24 bytes (amd64) and most of the commonly-used color/priority fields are less then 8 bits.
I'm wondering what's the reasoning on using multiple different mbuf tags on passing DS data, instead of a single one.