netdev - Re: [RFC] [PATCH] Optimize TCP sendmsg in favour of fast devices?

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <OF0D3FEC3A.84663D58-ON652576AC.0031CA59-652576AC.003232CF@in.ibm.com>
Date:	Fri, 15 Jan 2010 14:50:04 +0530
From:	Krishna Kumar2 <krkumar2@...ibm.com>
To:	Krishna Kumar2 <krkumar2@...ibm.com>
Cc:	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	ilpo.jarvinen@...sinki.fi, netdev@...r.kernel.org
Subject: Re: [RFC] [PATCH] Optimize TCP sendmsg in favour of fast devices?

Sorry, I sent off the reply sooner than I wanted to. continued at the
end...

Krishna Kumar2/India/IBM wrote on 01/15/2010 02:33:25 PM:


> Re: [RFC] [PATCH] Optimize TCP sendmsg in favour of fast devices?
>
> > David Miller <davem@...emloft.net>
> >
> > Re: [RFC] [PATCH] Optimize TCP sendmsg in favour of fast devices?
> >
> > From: Krishna Kumar <krkumar2@...ibm.com>
> > Date: Fri, 15 Jan 2010 11:03:52 +0530
> >
> > > From: Krishna Kumar <krkumar2@...ibm.com>
> > >
> > > Remove inline skb data in tcp_sendmsg(). For the few devices that
> > > don't support NETIF_F_SG, dev_queue_xmit will call skb_linearize,
> > > and pass the penalty to those slow devices (the following drivers
> > > do not support NETIF_F_SG: 8139cp.c, amd8111e.c, dl2k.c, dm9000.c,
> > > dnet.c, ethoc.c, ibmveth.c, ioc3-eth.c, macb.c, ps3_gelic_net.c,
> > > r8169.c, rionet.c, spider_net.c, tsi108_eth.c, veth.c,
> > > via-velocity.c, atlx/atl2.c, bonding/bond_main.c, can/dev.c,
> > > cris/eth_v10.c).
> >
> > I was really surprised to see r8169.c in that list.
> >
> > It even has all the code in it's ->ndo_start_xmit() method
> > to build fragments properly and handle segmented SKBs, it
> > simply doesn't set NETIF_F_SG in dev->features for whatever
> > reason.

> I didn't notice this driver but had checked via-velocity and
> found that it too had support but was not setting this bit.
>
> > Bonding it on your list, but it does indeed support NETIF_F_SG
> > as long as all of it's slaves do.  See bond_compute_features()
> > and how it uses netdev_increment_features() over the slaves.
> >
> > Anyways...
> >
> > > This patch does not affect devices that support SG but turn off
> > > via ethtool after register_netdev.
> > >
> > > I ran the following test cases with iperf - #threads: 1 4 8 16 32
> > > 64 128 192 256, I/O sizes: 256 4K 16K 64K, each test case runs for
> > > 1 minute, repeat 5 iterations. Total test run time is 6 hours.
> > > System is 4-proc Opteron, with a Chelsio 10gbps NIC. Results (BW
> > > figures are the aggregate across 5 iterations in mbps):
> >  ...
> > > Please review if the idea is acceptable.
> > >
> > > Signed-off-by: Krishna Kumar <krkumar2@...ibm.com>
> >
> > So how bad does it kill performance for a chip that doesn't
> > support NETIF_F_SG?
> >
> > That's what people will complain about if this goes in.
>
> I don't know how much performance will drop for those 15-18 drivers
> listed above, since I don't have access to those devices.

I wonder if there is some other way to test it. I could test it on
the card I have, cxgbe, by ethtool F_SG off, and then testing
this patch with existing code (both with ethtool F_SG off)? Will
that be enough to get an idea, or I cannot assume this is
reasonable for real non-sg drivers? I am sure there is a
degradation, and mentioned that part as a "penalty" for those
drivers in my patch.

Thanks,

- KK

--
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