netdev - Re: [PATCH v2 2/3] net_sched: Add accessor function for packet length for qdiscs

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080730.044851.135868050.davem@davemloft.net>
Date:	Wed, 30 Jul 2008 04:48:51 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	kaber@...sh.net
Cc:	jarkao2@...il.com, jussi.kivilinna@...et.fi, netdev@...r.kernel.org
Subject: Re: [PATCH v2 2/3] net_sched: Add accessor function for packet
 length for qdiscs

From: Patrick McHardy <kaber@...sh.net>
Date: Wed, 30 Jul 2008 13:40:22 +0200

> The reason why it translates it at all seems to be to not increase
> the drops counter. Within a single qdisc this could be avoided by
> other means easily, upper qdiscs would still increase the counter
> when we return anything besides NET_XMIT_SUCCESS though.
> 
> This means we need a new NET_XMIT return value to indicate this to
> the upper qdiscs. So I'd suggest to introduce NET_XMIT_STOLEN,
> return that to upper qdiscs and translate it to NET_XMIT_SUCCESS
> in dev_queue_xmit, similar to NET_XMIT_BYPASS.

Maybe these NET_XMIT_* values being passed around should be a set of
bits.

They could be composed of base meanings, combined with specific
attributes.

So you could say "NET_XMIT_DROP | __NET_XMIT_NO_DROP_COUNT"

The attributes get masked out by the top-level ->enqueue() caller,
such that the base meanings are the only thing that make their
way up into the stack.

If it's only about communication within the qdisc tree, let's
simply code it that way.

--
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