[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)
/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
-------------- 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