lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 04 Dec 2011 13:38:31 +0100 From: Michal Soltys <soltys@....info> To: "John A. Sullivan III" <jsullivan@...nsourcedevel.com> Cc: netdev@...r.kernel.org Subject: Re: Understanding HFSC On 11-12-04 05:57, John A. Sullivan III wrote: > Hello, all. I hope I am in the right place as this seems to be the > place to ask questions formerly asked on lartc. For the last three > days, I've been banging my head against the wall trying to understand > HFSC and it's finally starting to crack (the wall, not my head > although that's close, too!). It seems to be wonderful, powerful, > mysterious, and poorly understood. > > I'm not sure I understand it either but it also seems much of what is > written about it is written by people who don't fully grasp it, e.g., > mostly focusing on guaranteed bandwidth and hierarchical sharing but > not spending much time explaining the important concept of decoupling > latency requirements and bandwidth - the part most interesting to us. > So I'm hoping you'll indulge my questions and my attempt to articulate > my understanding to see if I get it or if I've completely missed the > plot! > > One of the most confusing bits to me is, does the m1 rate apply to > each flow handled by the class or only to the entire class once it > becomes active? Where a packet lands is (generally) determined by tc filters and/or iptables' mark/classify targets. All the packets that end in some leaf node, are governed by that node's realtime service curve, and at times when that criterion is not used - at the ratio of virtual times (coming from linkshare service curves) between that node and its siblings. Regardless of curve used - smallest vt (linkshare criterion) or smallest dt from all eligible (realtime criterion) wins, and the leaf with one will fulfill the dequeue call. If you need more fine grained control "below" such leaf node - you need to either use deeper hierarchy with presumably "simpler" qdiscs attached (but more complex marking setup), or shallower hierarchy with more elaborate qdiscs attached. Think of work conserving qdiscs such as: sfq, drr - paired with appropriate tc filters (tc-flow perhaps ?) as needed. Btw - check out the very latest iproute2 tree - there're fresh tc-hfsc(7) and tc-stab(8) manuals added. I tried to make them as detailed as possible, but I might have overshot a bit - so opinion of someone getting into hfsc territory is invaluable. You can read them (if installing fresh iproute2 is out of question) with simple: nroff -mandoc -rLL=<width>n <page> | less http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man7/tc-hfsc.7;hb=HEAD http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=blob_plain;f=man/man8/tc-stab.8;hb=HEAD > Second, what must go into the umax size? Let's assume we want umax to > be a single maximum sized packet on a non-jumbo frame Ethernet > network. > Should umax be: > 1500 > 1514 (add Ethernet) > 1518 (add CRC) > 1526 (add preamble) > 1538 (add interframe gap)? > > To keep this email from growing any longer, I'll put the rest in a > separate email? Thanks - John > Note: umax/dmax/rate and m1/d/m2 are just alternative ways to specify the very same thing. As for your question - in that particular case, assuming no vlan tags either, that would be 1514, afaik. You can cover for the rest though with tc-stab (and also for other layers, such as atm). Keep in mind, that if you don't disable send offloading (usually enabled by default these days), qdiscs might be dealing with e.g. massive tcp segments with typical side effects. I'll go through your other questions a bit later. -- 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