Roberto Nibali wrote:
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?
Not really..if someone wants this feature enabled, just use ethtool
to set the RX-ALL and/or SAVE_FCS. There's no reason for tcpdump or
ethereal to really worry about it..they will just get an extra 4 bytes
or not, and at least ethereal already deals with this just fine.
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.
Yes.
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.
I've never caught one in the wild. If you jiggle the cable in and
out you can sometimes generate crc errors, and if you overheat shitty
old 100Mbps NICs you could get them..but I threw away all the ones
that had this problem long ago.
I've passed 990+Mbps full duplex on pro/1000 NICs for hours w/out
seeing any errors..but I haven't looked closely at very long runs.
Either way, with non-broken hardware, crc errors are extremely rare.
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 ;).
It's more like it should be sysfs instead of procfs. And, the ioctls
would have to become netlink, or perhaps I could get by with ethtool
ioctl extensions.
The truth is, the current macvlan API is not very good and would need
to be cleaned up, even if we're able to stay with an ioctl API.
It's on my list of things to do, but because I haven't
seen much interest in getting it into the kernel, it's been pretty low
priority.
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?
My pktgen has diverged a lot. It is written in such a way that
it does not busy-spin, and it has hooks in dev.c to receive packets
so you can get round-trip statistics. It cannot go into the kernel
because the hook in dev.c is frowned upon.
The problem I was chasing was a null pointer exception..probably a
race, perhaps an access-after-free type thing, but I am not having
good luck figuring out where it is or reliably reproducing the problem.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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
