Julian Elischer wrote:
Ok which clever person did this again?
It just broke our product.
If it hasn't been removed from 7.0 and 6.x yet it's just about to be...
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
on the topic above, I've found that the bce driver seems to be throwingaway
packets
larger than the mtu regardless of the rest of the system..
the following code seems to be responsible..
in the spirit of "be generous on receive" as mentionned before,
should it be relaxed?
/* Calculate and program the Ethernet MTU size. */
ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + ifp->if_mtu +
ETHER_CRC_LEN;
DBPRINT(sc, BCE_INFO, "%s(): setting mtu = %d\n",__FUNCTION__,
ether_mtu);
/*
* Program the mtu, enabling jumbo frame
* support if necessary. Also set the mbuf
* allocation count for RX frames.
*/
if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) {
REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu |
BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA);
sc->mbuf_alloc_size = MJUM9BYTES;
} else {
REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu);
sc->mbuf_alloc_size = MCLBYTES;
}
could probably be relaxed in the non jumbo case to accept packets up to
MCLBYTES in size instead of ether_mtu.
manually I have set the mtu to larger values which increases
ether_mtu and that seems to work..
now, Why do we need this?
WCCP is a protocol from Cisco.
it encapsulates packets in GRE, including an extra intermediate header.
when packets are encapsulated in GRE by cisco 6k switches (quite a few around)
they do NOT frag the result, but instead, send an oversized packet.
if you have a bce interface, it discards these packets which is a drag.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
