Re: change the way e1000 is handling short VLAN frames
On 9/21/07, jamal [EMAIL PROTECTED] wrote: Hope that makes sense. [cut] cheers, jamal Hi all, as far as I understand ieee docs both 64 and 68 approaches are fine... --- Std 802.1Q-2005, 6.5.1 --- On receipt of an M_UNITDATA.request primitive that represents a tagged frame, the implementation is permitted to adopt either of the following approaches with regard to the operation of Transmit Data Encapsulation for frames whose length would, using the procedure as described, be less than 68 octets: a) Use the procedure as described in 6.5.1 of IEEE Std 802.1D. This procedure can result in tagged frames of less than 68 octets (but at least 64 octets) being transmitted; or b) Include additional octets before the FCS field in order for the transmitted frame length for such frames to be 68 octets. This procedure results in a minimum tagged frame length of 68 octets. When a tagged frame of less than 68 octets in length is received on a CSMA/CD LAN segment, and is forwarded as an untagged frame, the provisions of 6.5.1 of IEEE Std 802.1D, result in additional octets being included before the FCS field on transmission in order that the transmitted frame length meets the minimum frame size requirements of 3.2.7 in IEEE Std 802.3. -- and --- Std 802.1Q-2005, C.4.4.1 --- When tagged frames are transmitted by a Bridge on an IEEE Std 802.3 MAC, there are two permissible approaches (7.2), as follows: a) Keep the minimum frame size generated by the Bridge equal to 64 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would be reduced by up to 4 octets when that frame was tagged; b) Adopt a minimum tagged frame length of 68 octets. This implies that the number of pad octets in a received untagged IEEE Std 802.3 frame would not be adjusted when tagging such frames; equally, if subsequently untagged, no pad adjustment would be necessary before transmission on IEEE 802.3/Ethernet. -- might this problem be solved using a configurable parameter? (default=68) my 0.02 euro Ciao FF - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vlan support for pktgen
On 9/14/06, Robert Olsson [EMAIL PROTECTED] wrote: Thanks a lot, code seems code seems straight forward but I'm not to experienced with VLAN hacking and need find some test environment when I got a chance, maybe someone else has better opportunities to verify. Cheers. --ro ok BTW I wrote a patch for ethereal (new name's wireshark, www.wireshark.org) in order to parse pktgen data, I'll submit it to wireshark ml later, it should be checked in next release. You might find it useful when toying with pktgen ;-) Ciao FF - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] vlan support for pktgen
Hi all,
The attached patch allows pktgen to produce 802.1Q and Q-in-Q tagged frames.
I have used it for stress test a bridge and seems ok to me.
Unfortunately I have no access to net-2.6.x git tree so the diff is against
2.6.17.13.
If you have a moment look over it, I think this feature could be useful for
someone else.
mini-how-to (to be added to Documentation/networking/pktgen.txt):
pgset vlan_id 77 # to tag frames with VID 77
pgset svlan_id 88 # to double tag frames with SVID 88
pgset flag VID_RND # use random VID values
pgset flag SVID_RND # use random SVID values
you can set also p and cfi bits of Tag Control Information with:
pgset [s]vlan_p 5
pgset [s]vlan_cfi 1
pgset vlan_id # if id is 4095 you remove tagging
BTW I might have found a couple of bugs:
1)
At line 2432 (original code in 2.6.17.13):
2431 memcpy(eth, pkt_dev-hh, 12);
2432 *(u16 *) eth[12] = __constant_htons(ETH_P_IPV6);
//should be = protocol
IPv6 over MPLS packets get out malformed, ethernet protocol type is set to
ETH_P_IPV6 instead of ETH_P_MPLS_UC, so I've changed it the same way
it is in IPv4 case.
2)
At line:
2221 pkt_dev-seq_num++;
in fill_packet_ipv4() or at line:
2534 pkt_dev-seq_num++;
in fill_packet_ipv6() and at line 2913:
2910 if (likely(ret == NETDEV_TX_OK)) {
2911 pkt_dev-last_ok = 1;
2912 pkt_dev-sofar++;
2913 pkt_dev-seq_num++;
2914 pkt_dev-tx_bytes += pkt_dev-cur_pkt_size;
for each packet seq_num is incremented twice, so pktgen sequence number on wire
was 1, 3, 5, 7,... if this was intentional please change my patch
because I commented
line 2221 and line 2534 out.
Thank you
Ciao
FF
pktgen_vlan.patch
Description: Binary data
