Sean C. Farley wrote:
...
Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16],
yes? em(4) has an upper limit of 16114 for MTU. I could limit the
MTU to TAPMRU (16384) which is the limit for a write to the driver
anyway.
Just waiting for my VFS cache to spool up after a fres
On Fri, 13 Mar 2009, Bruce Simpson wrote:
Sean C. Farley wrote:
Yes, this fixes my issue with bridging a tap device to an interface
with an MTU higher than 1500. I will probably commit this patch this
weekend.
I can't think of any reason why not, other than you might want to
ensure that
Sean C. Farley wrote:
Yes, this fixes my issue with bridging a tap device to an interface
with an MTU higher than 1500.
I will probably commit this patch this weekend.
I can't think of any reason why not, other than you might want to ensure
that tap's MTU is bounded within reasonable limits
On Fri, 13 Mar 2009, Rui Paulo wrote:
On 13 Mar 2009, at 01:54, Sean C. Farley wrote:
Here is a patch[1] that will allow the MTU to be set higher than 1500
on a tap(4) interface. I ran into the need to do this when I had em0
set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU.
On 13 Mar 2009, at 01:54, Sean C. Farley wrote:
Here is a patch[1] that will allow the MTU to be set higher than
1500 on a tap(4) interface. I ran into the need to do this when I
had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for
QEMU. A bridge interface will not allow
Here is a patch[1] that will allow the MTU to be set higher than 1500 on
a tap(4) interface. I ran into the need to do this when I had em0 set
to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU. A bridge
interface will not allow interfaces with different MTU's to be added to
it.
