Yes, that's true. very good discussion. I bring this up since you can do
whatever you want on a point to point link.
For maximum compatibility, using 1500 or 1518 will help you handle all of
the cross-network cases
where you cross a bridge/switch or gateway.
The other unintended side-effect of thi
Technically, the MTU should be 1496 of you use VLANs, or else it's
> actually already a jumbo frame. The total size according to the ethernet
> spec is really 1518. Larger are not allowed. VLAN information is
> actually a part of the payload.
>
>
Yes, 1518 is the size, true. But VLANS are not part
On 2021-03-05 00:21, Gregory Nutt wrote:
On 3/4/2021 4:59 PM, James Dougherty wrote:
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big
Technically, the MTU should be 1496 of you use VLANs, or else it's
actually already a jumbo frame. The total size according to the ethernet
spec is really 1518. Larger are not allowed. VLAN information is
actually a part of the payload.
Also, if we have a length field, then it's an 802.3 frame
My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
has to be 1514? So that ultimately a frame must be received completely into
one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048
Hi John,
Jinx you owe me a soda! I am just debugging this same thing today.
This is happening on the F7 as well. It is a bug, in this line.
up_invalidate_dcache((uintptr_t)dev->d_buf,
(uintptr_t)dev->d_buf + dev->d_len);
It in performs cache inv
On 3/4/2021 4:59 PM, James Dougherty wrote:
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a l
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a lot, but for the best performance yes, both sides
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
One thing I am wondering is if you have properly set up the MAC address
filtering. For TCP, each peer a
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
I think this behavior is pretty clear from reading the H7 reference
manual. The H7 Ethernet MAC supports only three maximum packet size,
standard (1518 or 1522 if tagged), 2K, and Jumbo (9018 or 9022 if
tagged). The Jumbo packet selection is controlled by settings in registers.
So while 590
Disabling DMA is not a option on most Ethernet MACs.
On 3/4/2021 3:00 PM, Alan Carvalho de Assis wrote:
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a
On Thu, Mar 4, 2021 at 3:49 PM John Rippetoe
wrote:
>
> The fact that I have not done this yet has been haunting me for months.
> I think I sorted out the issues in the meantime and am trying to find
> time to at least rebase my changes on master and get a draft PR up for
> people to get eyes on.
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
Hi John,
You can check this very useful post about Hardfault in Cortex M in the
follow link:
-
https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults
Regards,
Oliver Miranda
Em qui., 4 de mar. de 2021 às 18:06, John Rippetoe <
jrippe...@roboticresearch.com> esc
Alan,
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
Thanks for the suggestion.
- John
On 3/4/21 4:00 PM, Alan Carvalho de Assis wrote:
Hi John,
Did
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a valid test to find
out the root causes.
BR,
Alan
On 3/4/21, John Rippetoe wrote:
> Hello All,
>
> I've
The fact that I have not done this yet has been haunting me for months.
I think I sorted out the issues in the meantime and am trying to find
time to at least rebase my changes on master and get a draft PR up for
people to get eyes on.
Sorry for the delay.
- John
On 12/29/20 4:37 PM, John Ri
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
19 matches
Mail list logo
