Znyx Networks bh5700 Manuale Utente
many packets sent as queue 0, queue 2 will have four times as many, and queue 3 will have six
times as many. wrr parameters are scaled such that the maximum value is no more than 15.
values which would be 0 are set to 1:
times as many. wrr parameters are scaled such that the maximum value is no more than 15.
values which would be 0 are set to 1:
•
Queue 0 has a weight of 1000 bytes
•
Queue 1 has a weight of 2000 bytes
•
Queue 2 has a weight of 4000 bytes
•
Queue 3 has a weight of 6000 bytes
The remaining commands each define a packet-limited FIFO queue. As with all previous tc
examples, these queues are created on device zhp0. However, unlike all previous examples,
they are not created as root disciplines for the device. Instead, the “parent” option identifies them
as child queues of the prio discipline.
examples, these queues are created on device zhp0. However, unlike all previous examples,
they are not created as root disciplines for the device. Instead, the “parent” option identifies them
as child queues of the prio discipline.
For example, “parent 100:1” identifies that queue as the first child of the prio discipline (Queue
0), because the prio discipline’s handle is 100:0.
0), because the prio discipline’s handle is 100:0.
After running each of those commands, again examine the CoS parameters. As with the simple
FIFO example, queue sizes change to 32 packets. In addition, though, the number of queues
changes to 4 for each port in zhp0. Furthermore, the weights have changed for each queue, as
have the queue mappings.
FIFO example, queue sizes change to 32 packets. In addition, though, the number of queues
changes to 4 for each port in zhp0. Furthermore, the weights have changed for each queue, as
have the queue mappings.
To test the strict priority case, simply remove the wrr 1 2 4 6 options from the first tc
command. Note that all queue disciplines in this test may be cleared by deleting the root
discipline, as before:
command. Note that all queue disciplines in this test may be cleared by deleting the root
discipline, as before:
tc qdisc del dev zhp0 root
The U32 Filter
The U32 filter provides the capability to match on fields in the L2, L3 or L4 header of a packet.
Each match rule gives the location of the field to be tested, which is always a 32 bit word, a mask
selecting the bits to be tested, and a value which is to be matched by the packet field. Many
matches can be specified in one tc filter command. Only if all matches succeed does the filter
match. In that case, the flowid field identifies the classid of the class this packet belongs in.
Each match rule gives the location of the field to be tested, which is always a 32 bit word, a mask
selecting the bits to be tested, and a value which is to be matched by the packet field. Many
matches can be specified in one tc filter command. Only if all matches succeed does the filter
match. In that case, the flowid field identifies the classid of the class this packet belongs in.
The following tc commands put all icmp packets in class 100:10, packets from IP address
1.2.3.4 in class 100:20. Packets for IP address 1.2.3.4 in class 100:20, and arp reply packets in
class 100:30. The last filter illustrates using an offset from the beginning of the protocol header,
along with a mask, to locate the field to be matched
1.2.3.4 in class 100:20. Packets for IP address 1.2.3.4 in class 100:20, and arp reply packets in
class 100:30. The last filter illustrates using an offset from the beginning of the protocol header,
along with a mask, to locate the field to be matched
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip
protocol 1 0xff flowid 100:10
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip src
1.2.3.4/32 flowid 100:20
1.2.3.4/32 flowid 100:20
tc filter add dev zhp0 protocol ip parent 100:0 u32 match ip dst
1.2.3.4/32 flowid 100:20
Ethernet Switch Blade User's Guide
release 3.2.2j
page 123