[Cerowrt-devel] cerowrt-3.10.34-4 dev build released

Török Edwin edwin+ml-cerowrt at etorok.net
Mon Apr 7 14:51:56 EDT 2014

On 04/07/2014 08:58 PM, Dave Taht wrote:
> On Mon, Apr 7, 2014 at 8:27 AM, Török Edwin <edwin+ml-cerowrt at etorok.net> wrote:
>> On 04/07/2014 05:45 PM, Toke Høiland-Jørgensen wrote:
>>> Török Edwin <edwin+ml-cerowrt at etorok.net> writes:
>>>> I hacked the script to set the interface name for iptables to pppoe-ge00 (not for uci, cause uci
>>>> doesn't have an enabled=1 for pppoe):
>>>>                 setup_ipset
>>>> +               interface=pppoe-ge00
>>>>                 setup_iptables "$interface"
>>>> Any idea how to fix this properly without hardcoding the interface
>>>> name?
>>> Editing the config file by hand should be sufficient rather than having
>>> to edit the script (it's in /etc/config/bcp38).
>> Thanks, that worked (both for /etc/config/bcp38 and /etc/config/sqm).
>> The netperf streams seem to be better separated with pppoe-ge00.png
> Um, er, I actually found the differences between these two graphs
> quite puzzling, as the fq_codel tc filter is supposed to be able to
> decode ppp frames and access the 5 tuple including the diffserv bits,
> which seems to be happening in the sqm-over-ppp case but not the
> sqm-over-normal-ethernet-with-encap-traffic case.
> It may be that the iptables rules don't work right on encapsulated
> traffic. :grump:
> Did you use simple.qos in both cases?

Yes, and I've run this prior to running /usr/lib/sqm/run.sh to clear the old rules:

IFACE=pppoe-ge00 /usr/lib/sqm/stop.sh
IFACE=ge00 /usr/lib/sqm/stop.sh
vi /etc/config/sqm (change the interface line)
... run netperf-wrapper again

> It might be easier to see a difference in performance if you use a
> closer server like demo.tohojo.dk.

Attached, the graphs are closer now, but so are the flows, is classification even working there?
Maybe I just have too much bandwidth there and not creating a bottleneck properly.

I tried using 1/10 of bandwidth, see _10th.png. The difference is much sharper, and pppoe-ge00_10th.png seems to be working, while ge00_!oth not.

> This is the relevant bit from net/core/flow_dissector.c
>         case __constant_htons(ETH_P_PPP_SES): {
>                 struct {
>                         struct pppoe_hdr hdr;
>                         __be16 proto;
>                 } *hdr, _hdr;
>                 hdr = skb_header_pointer(skb, nhoff, sizeof(_hdr), &_hdr);
>                 if (!hdr)
>                         return false;
>                 proto = hdr->proto;
>                 nhoff += PPPOE_SES_HLEN;
>                 switch (proto) {
>                 case __constant_htons(PPP_IP):
>                         goto ip;
>                 case __constant_htons(PPP_IPV6):
>                         goto ipv6;
>                 default:
>                         return false;
>                 }
>         }

TBH I don't know how PPPoE is actually implemented, who does the encapsulation? The kernel or the user-space daemon?
Would a packet capture on ge00/pppoe-ge00 help while running something that sets QoS bits (I'm guessing SSH would be good for that)?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ge00.png
Type: image/png
Size: 257302 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140407/4841cd1d/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pppoe-ge00.png
Type: image/png
Size: 255549 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140407/4841cd1d/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ge00_10th.png
Type: image/png
Size: 234196 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140407/4841cd1d/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pppoe-ge00_10th.png
Type: image/png
Size: 216757 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140407/4841cd1d/attachment-0011.png>

More information about the Cerowrt-devel mailing list