<div dir="ltr"><div>Hi Michael,</div><div> 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,.<br><a href="https://github.com/ipxe/ipxe/blob/c4c03e5be867a9b7be4dc48fe6576deca1dce8d8/src/net/netdevice.c#L868">https://github.com/ipxe/ipxe/blob/c4c03e5be867a9b7be4dc48fe6576deca1dce8d8/src/net/netdevice.c#L868</a>.<br><br></div><div>Please correct me if I am wrong.<br></div><div>Regards<br></div><div>Mohamed Shah R<br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 13, 2023 at 6:32 PM Michael Brown <<a href="mailto:mcb30@ipxe.org">mcb30@ipxe.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/03/2023 03:16, MohamedShah R via ipxe-devel wrote:<br>
>  1. If our device configures netdev->mtu as 1500  and<br>
>     netdev->max_pkt_len is 9128(above 9k).<br>
>  2. If the DHCP server sends MTU size as 9K.   <br>
> <br>
> As per the code walk-through, I understand that this api <br>
> "staticintapply_netdev_settings” get invoke and call the below part of <br>
> code to handle the above scenario: In this case, as part of netdev_close <br>
> , it gets called the intf_close and it didn’t call the intf_init/openas <br>
> part of netdev_open api.<br>
<br>
I think you've got lost somewhere in the code, sorry.  There is no path <br>
from netdev_close() to intf_close().  The generic object interfaces <br>
handled by intf_init(), intf_close(), etc, exist at a higher layer in <br>
the stack.<br>
<br>
An MTU change for an open network interface via apply_netdev_setting() <br>
will result in the network devices .close() and .open() methods both <br>
being called.  Since receive buffers are allocated during .open(), this <br>
will result in all receive buffers having the correct size for the new MTU.<br>
<br>
Michael<br>
<br>
</blockquote></div>