On 10/12/2023 6:02 PM, Maciej Żenczykowski wrote:
On Thu, Oct 12, 2023 at 1:48 AM Krishna Kurapati PSSNV
Could you paste the full patch?
This is hard to review without looking at much more context then email
is providing
(or, even better, send me a link to a CL in gerrit somewhere - for
example aosp ACK mainline tree)
Sure. Will provide a gerrit on ACK for review before posting v2.
The intent of posting the diff was two fold:
1. The question Greg asked regarding why the max segment size was
limited to 15014 was valid. When I thought about it, I actually wanted
to limit the max MTU to 15000, so the max segment size automatically
needs to be limited to 15014. But my commit text didn't mention this
properly which was a mistake on my behalf. But when I looked at the
code, limiting the max segment size 15014 would force the practical
max_mtu to not cross 15000 although theoretical max_mtu was set to:
(GETHER_MAX_MTU_SIZE - 15412) during registration of net device.
So my assumption of limiting it to 15000 was wrong. It must be limited
to 15412 as mentioned in u_ether.c This inturn means we must limit
max_segment_size to:
GETHER_MAX_ETH_FRAME_LEN (GETHER_MAX_MTU_SIZE + ETH_HLEN)
as mentioned in u_ether.c.
I wanted to confirm that setting MAX_DATAGRAM_SIZE to
GETHER_MAX_ETH_FRAME_LEN was correct.
2. I am not actually able to test with MTU beyond 15000. When my host
device is a linux machine, the cdc_ncm.c limits max_segment_size to:
CDC_NCM_MAX_DATAGRAM_SIZE 8192 /* bytes */
When connected to windows machine, I am able to set the mtu to a max
value of 15000. So not sure how to test the patch if I set the
max_segment_size to GETHER_MAX_ETH_FRAME_LEN.
By pasting the diff, I wanted to confirm both the above queries.
And you are right, while assigning value to ecm.wMaxSegmentSize, we must
use cpu_to_le16(...). Will ensure to make this change in v2. It worked
without that too, not sure how.
Let me know your thoughts on the above.
Regards,
Krishna,
