Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Andre Oppermann
On 21.08.2013 21:59, Navdeep Parhar wrote: On 08/21/13 12:41, Scott Long wrote: On Aug 21, 2013, at 8:59 AM, Andre Oppermann wrote: On 19.08.2013 23:45, Navdeep Parhar wrote: On 08/19/13 13:58, Andre Oppermann wrote: On 19.08.2013 19:33, Navdeep Parhar wrote: On 08/19/13 04:16, Andre Oppe

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Navdeep Parhar
On 08/21/13 12:41, Scott Long wrote: > > On Aug 21, 2013, at 8:59 AM, Andre Oppermann wrote: > >> On 19.08.2013 23:45, Navdeep Parhar wrote: >>> On 08/19/13 13:58, Andre Oppermann wrote: On 19.08.2013 19:33, Navdeep Parhar wrote: > On 08/19/13 04:16, Andre Oppermann wrote: >> Author

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Scott Long
On Aug 21, 2013, at 8:59 AM, Andre Oppermann wrote: > On 19.08.2013 23:45, Navdeep Parhar wrote: >> On 08/19/13 13:58, Andre Oppermann wrote: >>> On 19.08.2013 19:33, Navdeep Parhar wrote: On 08/19/13 04:16, Andre Oppermann wrote: > Author: andre > Date: Mon Aug 19 11:16:53 2013 >>>

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Peter Grehan
Hi Andre, On 21.08.2013 17:03, Peter Grehan wrote: The way to go should be 4K clusters as they are native to the architecture. IIRC a PCIe DMA can't cross a 4K boundary anyway That's a 4G boundary, for some devices. I meant a single PCIe DMA transaction can be at most 4K before it has to

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Andre Oppermann
On 21.08.2013 17:03, Peter Grehan wrote: The way to go should be 4K clusters as they are native to the architecture. IIRC a PCIe DMA can't cross a 4K boundary anyway That's a 4G boundary, for some devices. I meant a single PCIe DMA transaction can be at most 4K before it has to set up anoth

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Peter Grehan
The way to go should be 4K clusters as they are native to the architecture. IIRC a PCIe DMA can't cross a 4K boundary anyway That's a 4G boundary, for some devices. later, Peter. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mai

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Andre Oppermann
On 20.08.2013 00:03, Navdeep Parhar wrote: On 08/19/13 14:08, Andre Oppermann wrote: On 19.08.2013 19:40, Peter Grehan wrote: I recently tried some experiments to reduce the number of mbuf and cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved very useful and the code chan

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-21 Thread Andre Oppermann
On 19.08.2013 23:45, Navdeep Parhar wrote: On 08/19/13 13:58, Andre Oppermann wrote: On 19.08.2013 19:33, Navdeep Parhar wrote: On 08/19/13 04:16, Andre Oppermann wrote: Author: andre Date: Mon Aug 19 11:16:53 2013 New Revision: 254520 URL: http://svnweb.freebsd.org/changeset/base/254520 Log:

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Navdeep Parhar
On 08/19/13 14:08, Andre Oppermann wrote: > On 19.08.2013 19:40, Peter Grehan wrote: >>> I recently tried some experiments to reduce the number of mbuf and >>> cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved >>> very useful and the code changes to the kernel were minimal.

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Navdeep Parhar
On 08/19/13 13:58, Andre Oppermann wrote: > On 19.08.2013 19:33, Navdeep Parhar wrote: >> On 08/19/13 04:16, Andre Oppermann wrote: >>> Author: andre >>> Date: Mon Aug 19 11:16:53 2013 >>> New Revision: 254520 >>> URL: http://svnweb.freebsd.org/changeset/base/254520 >>> >>> Log: >>>Remove the u

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Adrian Chadd
fwiw - +1 on everything you've said to date about this. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Andre Oppermann
On 19.08.2013 19:40, Peter Grehan wrote: I recently tried some experiments to reduce the number of mbuf and cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved very useful and the code changes to the kernel were minimal. See user/np/cxl_tuning. The experiment was quite succ

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Andre Oppermann
On 19.08.2013 19:33, Navdeep Parhar wrote: On 08/19/13 04:16, Andre Oppermann wrote: Author: andre Date: Mon Aug 19 11:16:53 2013 New Revision: 254520 URL: http://svnweb.freebsd.org/changeset/base/254520 Log: Remove the unused M_NOFREE mbuf flag. It didn't have any in-tree users for a ve

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Peter Grehan
I recently tried some experiments to reduce the number of mbuf and cluster allocations in a 40G NIC driver. M_NOFREE and EXT_EXTREF proved very useful and the code changes to the kernel were minimal. See user/np/cxl_tuning. The experiment was quite successful and I was planning to bring in most

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Navdeep Parhar
On 08/19/13 04:16, Andre Oppermann wrote: > Author: andre > Date: Mon Aug 19 11:16:53 2013 > New Revision: 254520 > URL: http://svnweb.freebsd.org/changeset/base/254520 > > Log: > Remove the unused M_NOFREE mbuf flag. It didn't have any in-tree users > for a very long time, if ever. > >

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Andre Oppermann
On 19.08.2013 13:23, Davide Italiano wrote: On Mon, Aug 19, 2013 at 1:16 PM, Andre Oppermann wrote: Modified: head/sys/sys/mbuf.h == --- head/sys/sys/mbuf.h Mon Aug 19 11:08:36 2013(r254519) +++ head/sys/sys/mbu

Re: svn commit: r254520 - in head/sys: kern sys

2013-08-19 Thread Davide Italiano
On Mon, Aug 19, 2013 at 1:16 PM, Andre Oppermann wrote: > Author: andre > Date: Mon Aug 19 11:16:53 2013 > New Revision: 254520 > URL: http://svnweb.freebsd.org/changeset/base/254520 > > Log: > Remove the unused M_NOFREE mbuf flag. It didn't have any in-tree users > for a very long time, if e