Hi Michael, Thanks for your response. Below is the flow- I have seen in the execution- it hits the intf_close as part of netdev_close called from apply_netdev_settings,. https://github.com/ipxe/ipxe/blob/c4c03e5be867a9b7be4dc48fe6576deca1dce8d8/src/net/netdevice.c#L868 .
Please correct me if I am wrong. Regards Mohamed Shah R On Mon, Mar 13, 2023 at 6:32 PM Michael Brown <mc...@ipxe.org> wrote: > On 13/03/2023 03:16, MohamedShah R via ipxe-devel wrote: > > 1. If our device configures netdev->mtu as 1500 and > > netdev->max_pkt_len is 9128(above 9k). > > 2. If the DHCP server sends MTU size as 9K. > > > > As per the code walk-through, I understand that this api > > "staticintapply_netdev_settings” get invoke and call the below part of > > code to handle the above scenario: In this case, as part of netdev_close > > , it gets called the intf_close and it didn’t call the intf_init/openas > > part of netdev_open api. > > I think you've got lost somewhere in the code, sorry. There is no path > from netdev_close() to intf_close(). The generic object interfaces > handled by intf_init(), intf_close(), etc, exist at a higher layer in > the stack. > > An MTU change for an open network interface via apply_netdev_setting() > will result in the network devices .close() and .open() methods both > being called. Since receive buffers are allocated during .open(), this > will result in all receive buffers having the correct size for the new MTU. > > Michael > >
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel
