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

[MohamedShah R]

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 <mcb30 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20230313/9d16769c/attachment.htm>