Okay, so ya, I'm stupid. The MTU won't change w/ ifconfig on the command line because of the lagg/bridge. The real issue seems to be ifconfig ordering, eg:
ifconfig_cxgbe0="mtu 9000 toe4 toe6 up" Works ifconfig_cxgbe0="toe4 toe6 mtu 9000 up" Does NOT. So that's what was biting me in the butt. Sorry for the spam guys! -Dustin On Fri, May 27, 2016 at 2:29 AM, Navdeep Parhar <npar...@gmail.com> wrote: > On Fri, May 27, 2016 at 12:23:02AM -0700, K. Macy wrote: >> On Thursday, May 26, 2016, Navdeep Parhar <npar...@gmail.com> wrote: >> >> > On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote: >> > > In article < >> > cajpshy4vf5ky6guausloorogiquyd2ccrmvxu8x3carqrzx...@mail.gmail.com >> > <javascript:;>> you write: >> > > >> > > ># ifconfig -m cxgbe0 >> > > >cxgbe0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> >> > > >> > > ># ifconfig cxgbe0 mtu 9000 >> > > >ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument >> > > >> > > I believe this device, like many others, does not allow the MTU (or >> > > actually the MRU) to be changed once the receive ring has been set up >> > >> > This is not correct. You can change the MTU of a cxgbe/cxl interface at >> > any time (whether it's up or down, passing traffic or idle, etc.). >> >> >> For some reason the stack needs init to be called when the MTU is changed >> for it to actually change the size of the packets passed to the driver. At >> least cxgb does not do that. I'm not at my computer right now, but cxgbe >> may be the same. If that's the case just up / down the interface. It _will_ >> take effect without that if it's passed at module load. > > The problem that was reported was that the ioctl that sets the MTU > failed, not that the ioctl succeeded but the MTU change did not take > effect. > > Regards, > Navdeep _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
