Changing MTU on cxgbe

Dustin Marquess dmarquess at gmail.com
Fri May 27 17:32:53 UTC 2016


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 <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> wrote:
>>
>> > On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote:
>> > > In article <
>> > CAJpsHY4vF5Ky6GuAusLOOROgiQuyD2CcRmVxu8x3cArQRZxcbg at 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


More information about the freebsd-net mailing list