I'd love to see them in the kernel..I have cooresponding patches
for e100 and e1000 to support these features as well. However,
the e1000 maintainers were not interested last I checked...
I reckon we have new e1000 maintainers :). Is a 2.6.x version ready?
Yep, it's not a big change..and the critical piece came from in Intel
person originally. They just don't want to deal with the testing
effort since few people would use this feature...
Maybe you can send them along your use cases for testing and they can
verify. OTOH if it's only needed by a handful of people, it might not be
worth including it into the main kernel branch. At least pktgen could
support this feature.
On the longer run, well, the IFF_ACCEPT_ALL_FRAMES to me right now is
more of academic (pktgen et al) value and regarding IFF_SAVE_FCS I'm
not sure how people would use it. I don't see how not having
IFF_ACCEPT_ALL_FRAMES would reap VLAN/priority information? Wouldn't
this be a bug in tcpdump? Also how does the frame accounting work
using this flag? Bad frames are still incremented in the stats,
despite the kernel handling those frames.
Accept all frames just tells the NIC to send up pkts with busted CRC
and other errors that would normally cause the pkt to be dropped. Good
for sniffing..probably bad for normal processing. If you use this with
the SAVE_FCS option, then ethereal (and probably others) can receive a pkt
with bad CRC and show you the CRC. It does not break normal packet
processing.
So once your patches would go in, we would actually need to address
tcpdump and ethereal so they fall back to setting SAVE_FCS as soon as
RX_ALL is set?
It is likely to break bridging untill/unless bridging has a tweak to
realize to
drop the last 4 bytes before sending...
... which would be rather easy to come up with: Check for SAVE_FCS and
then trim the skb.
Regarding IFF_SAVE_FCS I could see a problem with handling the skb for
NICs that do no have this flag set. It would break horribly or you
would need to invent IFF_SEND_ALL_FRAMES.
I have another patch that allows you to specify the 4-byte ethernet CRC
on the end of a packet..that is what you are suggesting I believe.
Exactly.
I
used this to purposefully generate bogus packets to test the rx-all and
save-fcs. This feature is also useful for network testing applications,
perhaps for research into alternative crc methods..but otherwise pretty
much useless. It could be used in conjunction with rx-fcs and bridging
if you really wanted to.
Do you have number on how many CRC errors you got when using pktgen to
burst some packets over the wire, or locally? Since this could be
something NIC driver developers might be interested in addressing.
Slightely OT: What's the status of your VLAN MAC work? Is this for
submission as well?
Works good..would like to see it included..but it uses IOCTL interface
and /proc, both of which are frowned upon by the powers that be. Other
than it's use of un-cool API, it works just fine and has for several years.
Well, the proc-fs stuff is easily rewritten to seqfile. At some point in
the not so distant past I even believed S.Hemminger had a script to
convert all remaining places in the kernel to seqfile ;).
Meanwhile I've found your work on your OSS part of candelatech. Very
interesting to me.
Yep..my consolidated patches are there... A 2.6.15 patch will show up when
I figure out why pktgen is crashing on 2.6.15......
The standard one in the kernel or your additions?
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
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
