[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1318831799.2500.25.camel@edumazet-laptop>
Date: Mon, 17 Oct 2011 08:09:59 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Dan Siemon <dan@...erfire.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: Flow classifier proto-dst and TOS (and proto-src)
Le samedi 15 octobre 2011 à 12:51 -0400, Dan Siemon a écrit :
> cls_flow.c: flow_get_proto_dst()
>
> The proto-dst key returns the destination port for UDP, TCP and a few
> other protocols [see proto_ports_offset()]. For ICMP and IPIP it falls
> back to:
>
> return addr_fold(skb_dst(skb)) ^ (__force u16)skb->protocol;
>
> Since Linux maintains a dst_entry for each TOS value this causes the
> returned value to be affected by the TOS which is unexpected and
> probably broken.
Hi Dan
I think Patrick did this on purpose, because of of the lack of
perturbation in cls_flow.c : If all these frames were mapped to a single
flow, they might interfere with an other regular flow and hurt it.
I dont qualify existing code as buggy. Its about fallback behavior
anyway (I dont think its even documented)
If you have too many frames going to the fallback, then this classifier
is probably not the one you should use ?
Hint : You can change your filter to use this classifier only on TCP/UDP
trafic, and use another one on other protocols : Coupled to your qdisc
rules, you even can limit to X percent the bandwidth allocated to this
trafic
We could argue that if TOS value of two packets is different, then
packets belong to different flows as well. [ It seems we currently lack
a FLOW_KEY_TOS : that could be a usefull addition ]
--
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