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

["Török Edwin" <edwin+ml-cerowrt@etorok.net>]

[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

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@etorok.net> wrote:
>> On 04/07/2014 05:45 PM, Toke Høiland-Jørgensen wrote:
>>> Török Edwin <edwin+ml-cerowrt@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)
/usr/lib/sqm/run.sh
... 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)?

Thanks,
--Edwin

[-- Attachment #2: ge00.png --]
[-- Type: image/png, Size: 257302 bytes --]

[-- Attachment #3: pppoe-ge00.png --]
[-- Type: image/png, Size: 255549 bytes --]

[-- Attachment #4: ge00_10th.png --]
[-- Type: image/png, Size: 234196 bytes --]

[-- Attachment #5: pppoe-ge00_10th.png --]
[-- Type: image/png, Size: 216757 bytes --]