Re: CVS commit: src/sys/kern
On 10/04/2020 23:34, Andrew Doran wrote: Module Name:src Committed By: ad Date: Fri Apr 10 22:34:36 UTC 2020 Modified Files: src/sys/kern: vfs_mount.c Log Message: vfs_mountroot(): don't needlessly grab a second reference to the root vnode (the kernel never chdirs) nor a lock on it. So the kernel chrooting to sysctl init.root is still ok? Roy
Re: CVS commit: src/share/man/man4
On Fri, Apr 10, 2020 at 07:16:24AM -0700, Jason Thorpe wrote: > > > On Apr 10, 2020, at 4:44 AM, m...@netbsd.org wrote: > > > > I had to stop using m_defrag because implementation details broke > > bwfm@pci. It can only handle a chain of length 1, and m_defrag gives > > a minimum of 2. > > Exactly. If it can compact the packet into a single cluster mbuf, it should > do so. It makes it slightly more difficult to use correctly, but those would > be better semantics. > > -- thorpej > At the time people brought up freebsd m_collapse or pre-allocating and using m_copydata. I haven't tried either, and bwfm@pci stopped working entirely for me anyway.
Re: CVS commit: src/share/man/man4
> On Apr 10, 2020, at 4:44 AM, m...@netbsd.org wrote: > > I had to stop using m_defrag because implementation details broke > bwfm@pci. It can only handle a chain of length 1, and m_defrag gives > a minimum of 2. Exactly. If it can compact the packet into a single cluster mbuf, it should do so. It makes it slightly more difficult to use correctly, but those would be better semantics. -- thorpej
Re: CVS commit: src/share/man/man4
On Fri, Apr 10, 2020 at 11:19:02AM +0900, SAITOH Masanobu wrote: > On 2020/04/10 2:42, David Young wrote: > > On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote: > > > On 2020/04/09 11:08, David Young wrote: > > > > On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote: > > > > > on I219 I observe about 35% transmit performance drop when tso4 > > > > > enabled > > > > > > > > This sounds familiar. There was a bug affecting TCP segmentation > > > > offload (I think) that we found at CoyotePoint. ISTR > > > > bus_dmamap_load_mbuf(9) failed with EFBIG because under some > > > > circumstances the number of segments in the DMA map was too small > > > > for the mbuf chain. The driver would drop the whole mbuf chain > > > > on the floor. This showed up as terrible performance under some > > > > circumstances---possibly when the TCP window grew long? The solution > > > > was to increase the number of DMA segments, *I think*. > > > > > > m_defrag() was added to -current in September 2018, and 9.0, > > > 8.1, post 7.2 have this code. > > > > Thank you, that's just the change I was thinking of. > > You're welcome. > Some drivers still have no m_defrag() code, so we should add it > to them(). I had to stop using m_defrag because implementation details broke bwfm@pci. It can only handle a chain of length 1, and m_defrag gives a minimum of 2.
