Date: Wed, 7 Nov 2012 20:53:14 -0800 From: Adrian Chadd <adrian@freebsd.org> To: pyunyh@gmail.com Cc: FreeBSD Net <freebsd-net@freebsd.org>, Pyun YongHyeon <yongari@freebsd.org> Subject: Re: svn commit: r242739 - stable/9/sys/dev/ti Message-ID: <CAJ-Vmoma1DJRT8_ezdEpVYrZXak%2B2B4mBHAPxhoUKr0nUrO6YQ@mail.gmail.com> In-Reply-To: <20121108023858.GA3127@michelle.cdnetworks.com> References: <201211080206.qA826RiN054539@svn.freebsd.org> <CAJ-VmomEOPGbLwmOmL0EdenZA7QKbV5P-hAYsTRcwLao2LbAqg@mail.gmail.com> <20121108023858.GA3127@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 November 2012 18:38, YongHyeon PYUN <pyunyh@gmail.com> wrote: > On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote: >> So I am curious - did this give a real benefit? > > In 3.x/4.x days it surely have had helped a lot, I guess mainly > because the CPU was not fast enough to saturate the link with > software checksum(i.e. NFS over UDP). Right. > Generally I prefer correctness to performance and it seems there > is no easy way to get full advantage of TCP/UDP checksum offloading > of controller on fragmented IP packets on FreeBSD 8+. So I disabled > it to reduce the chance of generating corrupted packets. Right. The problem here is that if_transmit pushes the locking to the driver, but there's no way to guarantee that the frames aren't interleaved with other parallel invocations of if_transmit(). Since SMP in 3.x and 4.x didn't really support multiple CPUs in kernel space, this wouldn't have been a problem. Ie, the network layer didn't explicitly define the behaviour with concurrent kernel senders, because that concept didn't exist yet. >> If so, may I suggest we perhaps accelerate discussing if_transmit() of >> multiple frames per call? > > Hmm, actually I'm still not a fan of if_transmit() at this moment. > Honestly I don't have good queuing code in driver to handle queue > full condition. Interactions with altq(9) is also one of my > concern as well as packet reordering issue of drbr(9) interface. > Well, can you provide me with some embedded hardware that has this particular NIC and multiple CPUs? I'd like to tinker with this but the SMP systems I have contain em NICs and I don't really feel up to hacking up this idea on the em(4) driver. :-) I have a vague idea of making if_transmit() as an interface be able to send multiple frames at once - so the TCP/UDP code could generate all the fragments and fire them off at once to the NIC. This should fix your issue and begin allowing devices to take advantage of multiple-dispatch rather than one if_transmit() call at a time. We could create a device or interface flag that indicates whether the driver can handle multiple mbufs chained via m_nextpkt through if_transmit(), and then teach one or two drivers that particular logic. What do you think? Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmoma1DJRT8_ezdEpVYrZXak%2B2B4mBHAPxhoUKr0nUrO6YQ>