Changing MTU on cxgbe

K. Macy kmacy at freebsd.org
Fri May 27 07:38:08 UTC 2016


On Friday, May 27, 2016, Navdeep Parhar <nparhar at gmail.com> wrote:

> On Fri, May 27, 2016 at 12:23:02AM -0700, K. Macy wrote:
> > On Thursday, May 26, 2016, Navdeep Parhar <nparhar at gmail.com
> <javascript:;>> wrote:
> >
> > > On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote:
> > > > In article <
> > > CAJpsHY4vF5Ky6GuAusLOOROgiQuyD2CcRmVxu8x3cArQRZxcbg at mail.gmail.com
> <javascript:;>
> > > <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.



Sorry. Continue on.
-M

>
> 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
>


More information about the freebsd-net mailing list