On 8/25/06, Michael Chan <[EMAIL PROTECTED]> wrote:
The reason is that TSO on 5704 and older chips is done by firmware. ASF
is also implemented by firmware. If ASF is enabled, there is no room to
do TSO and ASF at the same time.
Just for test purpose, I have applied the following patch to my tg3.c. I now
seem to be able to enable/disable TSO, but I admit don't know whether ASF
is still functional or not.
else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5700 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701 ||
- tp->pci_chip_rev_id == CHIPREV_ID_5705_A0 ||
- (tp->tg3_flags & TG3_FLAG_ENABLE_ASF) != 0) {
+ tp->pci_chip_rev_id == CHIPREV_ID_5705_A0) {
tp->tg3_flags2 &= ~TG3_FLG2_TSO_CAPABLE;
} else {
Then tg3 considered my interface as TSO-capable ("TSOcap[1]" in dmesg).
TSO was still disabled by default, which is normal because there is this other
check a couple of lines below:
/* TSO is on by default on chips that support hardware TSO.
* Firmware TSO on older chips gives lower performance, so it
* is off by default, but can be enabled using ethtool.
*/
if (tp->tg3_flags2 & TG3_FLG2_HW_TSO)
dev->features |= NETIF_F_TSO;
But I was able to turn TSO on via ethtool -K. This is exactly the behavior I
would like to see in tg3. So are you saying the patch I applied actually
breaks ASF ?
Firmware-based TSO is actually slower than no TSO. The only benefit is
a little better CPU utilization.
I know, in one of my test-cases, firmware TSO reduces the max achievable
TCP bandwidth from 930 to 840 Mbit/s on a GigE network while reducing
the CPU utilization from 44% to 22%. I think firmware TSO still makes sense
in some cases.
--
Marc Bevand
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
