Eric Dumazet writes:
> On 04/27/2018 06:38 AM, Toke Høiland-Jørgensen wrote:
>>
>> Ah, right. Will fix.
>>
>> Is it safe to dereference the iph pointer before calling
>> pskb_may_pull()?
>
> No, please take a look at ip_rcv() for a typical use case.
Will do, thanks.
On 04/27/2018 06:38 AM, Toke Høiland-Jørgensen wrote:
>
> Ah, right. Will fix.
>
> Is it safe to dereference the iph pointer before calling
> pskb_may_pull()?
No, please take a look at ip_rcv() for a typical use case.
Eric Dumazet writes:
> On 04/27/2018 05:17 AM, Toke Høiland-Jørgensen wrote:
>
> ...
>
>> +
>> +static struct sk_buff *cake_ack_filter(struct cake_sched_data *q,
>> + struct cake_flow *flow)
>> +{
>> +int seglen;
>> +struct
On 04/27/2018 05:17 AM, Toke Høiland-Jørgensen wrote:
...
> +
> +static struct sk_buff *cake_ack_filter(struct cake_sched_data *q,
> +struct cake_flow *flow)
> +{
> + int seglen;
> + struct sk_buff *skb = flow->tail, *skb_check, *skb_check_prev;
> +
sch_cake targets the home router use case and is intended to squeeze the
most bandwidth and latency out of even the slowest ISP links and routers,
while presenting an API simple enough that even an ISP can configure it.
Example of use on a cable ISP uplink:
tc qdisc add dev eth0 cake bandwidth