|
Post by malbolge on Jan 8, 2024 14:03:19 GMT
The MTUSize property is defined for both schemas, however the description differs. NetworkDeviceFunction->Ethernet->MTUSize: The maximum transmission unit (MTU) configured for this network device function. This value serves as a default for the OS driver when booting. The value only takes effect on boot. EthernetInterface->MTUSize: This property shall contain the size, in bytes, of largest protocol data unit (PDU) that can be passed in an Ethernet (MAC) frame on this interface. This is my understanding, not sure if correct - would appreciate a look: Note: The driver wouldn't actually write into EI Resource, rather it would make a configuration change through other channels to the device that results in EI->MTU being 6000. In particular: 1) It's ok and normal for NDF->MTU to differ from EI->MTU 2) Until driver loads, EI->MTU is non-applicable. After driver loads NDF->MTU is not relevant (until driver is unloaded anyway) 3) There's no single place where the current MTU can be obtained - the user must know whether the driver is loaded or not and use either NDF->MTU or EI->MTU 4) EI schema as a whole is N/A until driver is loaded and OS has network interfaces up (if you can't see the interface in netstat, EI won't function as a Resource) 5) If I want to change the MTU of my device after boot so that applications on my OS can send jumbo frames, I should be doing so only though EI->MTU and not NDF->MTU Edit: This thread might need to be moved to CSDL subforum.
|
|
|
Post by malbolge on Jan 10, 2024 20:02:31 GMT
Anyone have an opinion perhaps? Thoughts on the subject?
|
|
|
Post by mraineri on Jan 11, 2024 13:19:39 GMT
At least going based on your numbered list of comments, I agree with your assessment. The other thing to add to this subject is NetworkDeviceFunction is really meant to expose hardware control of the network device, whereas EthernetInterface controls software on top of the interface. Originally we had envisioned the ACD model with NetworkDeviceFunction would replace EthernetInterface (like how Storage is a proper replacement for SimpleStorage), but as we grew the model we began to find use cases where EthernetInterface really can't be removed (such as with virtual NICs, bonded NICs, and virtual machines). I think if we had understood these use cases early on, we would have taken a different approach to the model.
|
|