[OpenWrt-Devel] Lantiq xrx200: PTM issues

[Martin Schiller]

Ok, I think I've got it:

The "sk_wmem_alloc" is decremented in sock_wfree() which is called
by kfree_skb.

But in ptm_hard_start_xmit() of the ifxmips_ptm_vdsl.c, the skb
only gets freed immediately, if the skb_headroom is to small or
the skb is cloned. In this case the skb is copied to a new one and
the original skb gets freed.

Otherwise the skb only gets freed after a complete round through
the TX descriptor table.

My suggestion would be, to always copy the skb.

- Martin

On 2020-01-20 13:45, Martin Schiller wrote:
> Update:
> 
> I've found out now that the ENOBUFS is set by __ip_append_data,
> because sk_wmem_alloc "overflows".
> 
> Martin
> 
> 
> On 2020-01-20 07:09, Martin Schiller wrote:
>> Hi!
>> 
>> I have discovered the following problem:
>> 
>> If you have established a PPPoE session via VDSL / PTM connection 
>> incl.
>> VLAN tagging and send data with a relatively small send buffer
>> (SO_SNDBUF), then an ENOBUFS always comes back.
>> 
>> We first noticed this with stagnating data transfers over an OpenVPN
>> connection.
>> 
>> Also with iputils-ping, since by default the send buffer is relatively
>> small.
>> 
>> You can also force this with busybox ping by using
>> 
>> echo "5000"> / proc / sys / net / core / wmem_default
>> 
>> minimizes the system default value.
>> 
>> Then you send pings with a packet size of e.g. 4000 bytes and the
>> second package is already in the pants:
>> 
>> ------------------------------------------------------------
>> root @ OpenWrt: ~ # ping -s4000 10.200.1.142
>> PING 10.200.1.142 (10.200.1.142): 4000 data bytes
>> 4008 bytes from 10.200.1.142: seq = 0 ttl = 63 time = 20.519 ms
>> ping: sendto: No buffer space available
>> root @ OpenWrt: ~ #
>> ------------------------------------------------------------
>> 
>> So it should be easily reproducible for everyone.
>> 
>> Traffic that is only routed through the router is not affected.
>> 
>> The manpage of sendto says:
>> -----------------------------------------------------------------------
>> ENOBUFS
>>     The output queue for a network interface was full. This generally
>>     indicates that the interface has stopped sending, but may be 
>> caused
>>     by transient congestion. (Normally, this does not occur in Linux.
>>     Packets are just silently dropped when a device queue overflows.)
>> -----------------------------------------------------------------------
>> 
>> But all former packets have already been transmitted.
>> 
>> This issue seems to be in there since lede-17.01.
>> 
>> I can't reproduce it with owrt-15.05.
>> 
>> Does anyone have any idea how to solve the problem?
>> 
>> Martin
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel