<sb0>
jumbo frames are also optional, but are causing a bug right now anyway
<sb0>
_florent_, btw, what should be the behavior of liteeth when receiving a frame above the MTU?
<sb0>
I have set it to 9000 right now, which corresponds to most implementation of jumbo frames, but according to murphy's law, a liteeth device will soon be connected to a network that has a higher mtu
<_florent_>
2s looking at that
<_florent_>
for netif->mtu, yes that's probably 1500 for non jumbo frame, and then 9000 for jumbo
<_florent_>
looking at liteeth behaviour with too large frames...
<sb0>
I think a good behavior would be a large (eg 32-bit) length counter that always gives the full length of the frame
<sb0>
we might have to go for the non-jumbo frames
<_florent_>
btw why are you using jumbo frames?
<sb0>
the nist network has them
<sb0>
and will mercilessly send them to the device without asking questions
<_florent_>
ok, but do you need to receive them or just discard them (if I fix the gateware we will be able to discard them)
<sb0>
I think the best course of action is to support them, since this will decrease network latency (otherwise the sender has to retry at least one frame to determine the MTU)
<_florent_>
ok, at least on my side I'll fix the gateware soon (in the weekend)
<_florent_>
(just need to add a simulation for it)
<sb0>
if this isn't possible due to e.g. another avalanche of lwip bugs, then I think we should be sending back ICMP error replies when receiving a jumbo frames
fengling has quit [Ping timeout: 240 seconds]
sb0 has quit [Quit: Leaving]
kuldeep has quit [Ping timeout: 246 seconds]
kuldeep has joined #m-labs
<rjo>
sb0: i never said that it complained.
<rjo>
and how much BRAM does it actually use for that? with ISE on S3 it definitely used the next higher power of two.
<rjo>
do jumbo frames really provide a significant benefit here? can't we just properly detect too large frames in the mac and tell lwip about them?