Jumbo multicast

[Till Straumann]

Amedeo Perazzo wrote:
> Till,
>
> These are the problems I see when I try to send jumbo multicast 
> packets from RTEMS:
>
> 1. Packets get fragmented on the 1500 bytes boundary even if I setup 
> the interface to use jumbo frames.
>
> 2. The 2nd fragment of a large packet causes an arp request even if 
> the original packet is a multicast packet.
>
> I suspect that the following points are the causes for the above 
> behavior.
>
> 1. The mtu for the interface is reset to 1500 by ether_ifattach() even 
> if I set it to 9000 when I initialize the ifnet interface structure. 
> Note that the RTEMS documentation (at least the version for 4.6.6) 
> claims that the user should set the mtu variable _before_ calling 
> ether_ifattach().
>
> As a workaround I currently set ifp->mtu _after_ calling 
> ether_ifattach(). In any case, I claim I should be able to configure 
> the mtu before calling ether_ifattach().
Hmm - not sure about that. Seems that if we require drivers to set 
if_mtu prior to
calling ether_ifattach() we possibly break a lot of existing code. IMO 
setting
if_mtu after ether_ifattach by drivers which support longer frames should
be acceptable. Of course, the documentation should be updated...
>
>
> 2. The M_MCAST flag does not get copied by m_copym() for the 2nd 
> fragment in a packet and, as a consequence, arpresolve() in if_ether.c 
> does not enter the following condition:
>
>         if (m->m_flags & M_MCAST) {    /* multicast */
>         ETHER_MAP_IP_MULTICAST(&SIN(dst)->sin_addr, desten);
>         return(1);
>     }
>
> This seems to cause the arp request to be sent when it should not be.
>
> What do you think?
This one looks more serious. I did only have a quick glance but you may have
a point there. We should have a look at more recent BSD sources and see
if and how they fixed this.

-- T.
>
> -- Amedeo