[ipxe-devel] REG: Query on 9K MTU Testing flow

[MohamedShah R]

Hi Michael,

Thanks for the quick response. I am new to the PXE source code and tried
out the below changes  for the experimental testing in the netdev_close api
and it works fine.
Why can't we have a new api netdev_reopen() which does the same logic of
netdev_close (except the code below) and calls the netdev_open existing api
and calls the netdev_reopen api only from the "apply_netdev_settings".
Would it have any other side-effects? Please correct me if I am wrong.

*Commented out the below code in netdev_close api *
     num_configs = table_num_entries ( NET_DEVICE_CONFIGURATORS );
     for ( i = 0 ; i < num_configs ; i++ )
      intf_close ( &netdev->configs[i].job, -ECANCELED );

Regards
Mohamed Shah R
On Tue, Mar 14, 2023 at 7:15 PM Michael Brown via ipxe-devel <
ipxe-devel at lists.ipxe.org> wrote:

> On 13/03/2023 21:31, Michael Brown via ipxe-devel wrote:
> > There is what looks like a bug when using DHCP to change MTU: the change
> > of MTU requires the interface to be closed and reopened, but closing the
> > interface will cause the initiating DHCP transaction itself to be
> aborted.
> >
> > This probably requires the code in netdevice.c to be refactored slightly
> > to allow for a netdev_reopen() call, which skips the intf_close() calls.
>
> This is going to be very messy to support cleanly.  The combination of
> performing a close and reopen is fairly disruptive.  There are several
> other side effects from netdev_close() and netdev_open() (e.g. moving
> the device to the front of the "opened devices" list), which should
> probably be bypassed on an MTU change.
>
> I have a draft change in the "mtureset" branch.  However, even with this
> added complexity, there is still the problem that on several drivers a
> close/reopen will have other disruptive side effects such as restarting
> autonegotiation.
>
> I don't see a resolution to this any time soon.  Arguably the simplest
> workaround would be to remove the
>
>     .tag = DHCP_MTU,
>
> from the definition of mtu_setting.  This would prevent the MTU from
> being changed automatically by DHCP.  A script could still set the MTU
> explicitly using e.g.
>
>    set netX/mtu ${netX.dhcp/26}
>
> Michael
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20230314/9d89e27d/attachment.htm>