netdev - r8169: problem with TSO (TX_BUFFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1336430144.11363.35.camel@blackbone.local>
Date:	Tue, 08 May 2012 00:35:44 +0200
From:	Julien Ducourthial <jducourt@...e.fr>
To:	nic_swsd@...ltek.com, romieu@...zoreil.com
Cc:	netdev@...r.kernel.org, kernel@...r.kernel.org
Subject: r8169: problem with TSO (TX_BUFFS_AVAIL negative value)

Hi,

Whenever I activate TSO on my realtek based NIC, it gets stuck after a
while under heavy traffic (both under an zotac amd board with a 8111e on
board and an intel D510MO atom with 8111d on board).

After doing some investigation (with systemtap), the problem seems to be
that the net_device is not stopped when all TX descriptors are in use.

This behavior comes from the macro TX_BUFFS_AVAIL(tp). It is an unsigned
expression but returns -1 when the transmit queue is full (the macro
handles the room for the skb and the frags). 

This condition only happens when you have skb with lots of frags
(otherwise the nic is stopped before all TX desc are in use), hence only
in the tso case for me.

I made a small patch to avoid negative values, and the driver works
great with TSO. With my atom based board I can now reach maximum
throughput as an NFS server.

Best regards,

Julien Ducourthial (1):
  r8169: fix problem with TSO (TX_BUFFS_AVAIL negative value)

 drivers/net/ethernet/realtek/r8169.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html