Re: bge(4) Jumbo support for newer chipsets

2014-09-01 Thread Brad Smith
On Wed, Aug 27, 2014 at 02:25:27AM -0400, Brad Smith wrote: > Looking for some testing of the following diff to add Jumbo support for the > BCM5714 / BCM5780 and BCM5717 / BCM5719 / BCM5720 / BCM57765 / BCM57766 > chipsets. Here is an updated diff with bge_rxrinfo() being fixed. Index: if_bge.c

Re: bge(4) Jumbo support for newer chipsets

2014-09-01 Thread David Gwynne
if noone else is going to try this then i think it should go in. On 28 Aug 2014, at 20:32, David Gwynne wrote: > > On 28 Aug 2014, at 3:02 am, Mike Belopuhov wrote: > >> On 27 August 2014 08:25, Brad Smith wrote: >>> Looking for some testing of the following diff to add Jumbo support for the

Re: UPDATE: xkeyboard-config 2.12

2014-09-01 Thread Daniel Jakots
On Mon, 1 Sep 2014 20:52:49 +0600, Alexandr Shadchin wrote: > Hi, > > This diff updates xkeyboard-config to the latest release 2.12. > Also includes diff from > http://marc.info/?l=openbsd-tech&m=140750210214198&w=2 Tested on > amd64 and i386. > > Comments ? OK ? > Compiled on amd64 on my x20

Re: minphys woes

2014-09-01 Thread David Gwynne
On 1 Sep 2014, at 9:22 pm, Mike Belopuhov wrote: > On 1 September 2014 13:06, Stefan Fritsch wrote: >> On Mon, 1 Sep 2014, Mike Belopuhov wrote: >> >>> On 29 August 2014 22:39, Stefan Fritsch wrote: Yes, that seems to be what happens. But if every adapter needs to support transfers

Re: minphys woes

2014-09-01 Thread Mike Belopuhov
On 1 September 2014 13:06, Stefan Fritsch wrote: > On Mon, 1 Sep 2014, Mike Belopuhov wrote: > >> On 29 August 2014 22:39, Stefan Fritsch wrote: >> > Yes, that seems to be what happens. But if every adapter needs to support >> > transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for

Re: minphys woes

2014-09-01 Thread Stefan Fritsch
On Mon, 1 Sep 2014, David Gwynne wrote: > > Yes, that seems to be what happens. But if every adapter needs to support > > transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the > > adapter to be able to override the default minphys function with its own. > > And adapters that on

Re: minphys woes

2014-09-01 Thread Stefan Fritsch
On Mon, 1 Sep 2014, Mike Belopuhov wrote: > On 29 August 2014 22:39, Stefan Fritsch wrote: > > Yes, that seems to be what happens. But if every adapter needs to support > > transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the > > adapter to be able to override the default minph

Re: reduce the number of missed PCB cache with tcpbench -su

2014-09-01 Thread Mike Belopuhov
On 29 August 2014 18:01, Damien Miller wrote: > What's the benefit of this? This creates a UDP PCB per connection. Otherwise we always rely on matching the wildcard PCB. > I've never seen an application do this; I doubt that. However, things like NTP or DNS servers usually expect requests fro

Re: minphys woes

2014-09-01 Thread Mike Belopuhov
On 29 August 2014 22:39, Stefan Fritsch wrote: > On Fri, 29 Aug 2014, Mike Belopuhov wrote: >> correct me if i'm wrong, but what happens is that bread being a block >> read reads up to MAXBSIZE which is conveniently set to 64k and you can't >> create a filesystem with a larger block size. >> >> ph

Re: Kill rtalloc()

2014-09-01 Thread Martin Pieuchot
On 21/08/14(Thu) 15:36, Martin Pieuchot wrote: > As you might have seen, I started looking at routing entries pointing to > stale ifa's. This is a necessary step if we want to rely on our routing > entries to do address lookups. > > This audit leads me to believe that the actual check used to det