From: Declan Conlon <dconlon@zeus.com>
To: lartc@vger.kernel.org
Subject: [LARTC] Setting priority in userspace gets ignored
Date: Thu, 09 Sep 2004 17:31:05 +0000 [thread overview]
Message-ID: <41409359.5020002@zeus.com> (raw)
Briefly what I am trying to achieve is using the HTB qdisc to handle
traffic generated from
userspace. To achieve this I create a standard Gold/Silver/Bronze
configuration as follows;
tc qdisc add dev eth0 root handle 1: htb default 12
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1mbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512kbit ceil 100mbit
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 1kbit ceil 100mbit
Then according to the documentation setting the SO_PRIORITY socket
option in the
appropriate manner i.e. routing traffic to the class 1:10 should set the
priority to 65546,
MAJOR in the high bits and MINOR in the low bits. I have the correct
capability to set this
out of the 0-7 range and the setsockopt returns no error.
The problem I have is that the skb->priority field is not set when I get
to the htb_classify function
via the htb_enqueue function. That is that the skb->sk and skb->priority
fields are both zero.
As a result control falls through until the default class is selected.
The small test I am using is that
my application simply sets all of the outgoing data to a single priority.
And it is not set to the default :-)
I have tracked it down as far as the ip_queue_xmit function in
net/ipv4/ip_output.c.
There the skb->priority and the skb->sk field are correct however we go
through the NF_HOOK,
which is where I got lost.
There is no reason I can think of that a socket should lose any of it's
options between these two
points in the code. Could someone who understands the intermediate code
let me know if this is a
problem with the code or with the way I am setting the option on the socket.
Thanks for any help you can give.
Declan Conlon
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
reply other threads:[~2004-09-09 17:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41409359.5020002@zeus.com \
--to=dconlon@zeus.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.