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 rea
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
- use iproute2 and see how one dumps netdevice stats
- Continue by looking at iproute2/ip/
files iplink.c and ipaddress.c
and note that: stats are stored in a TLV IFLA_STATS and are printed in
print_linkinfo()
The code is not much to study if you are serious about performance.
Thomas Graf as wel
jamal wrote:
On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote:
jamal wrote:
And if you are serious about performance you should use netlink.
If you can show me a snippet of user-space code similar to the
complexity of what I posted earlier, I'll actually do a benchmark
against it and m
On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote:
> jamal wrote:
> > And if you are serious about performance you should use netlink.
>
> If you can show me a snippet of user-space code similar to the
> complexity of what I posted earlier, I'll actually do a benchmark
> against it and my code
jamal wrote:
On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote:
shemminger wrote:
It makes no sense to extend ethtool for something generic like that.
It shouldn't be that hard to do netlink in some richer scripting
language (like perl), but I haven't tried.
If you're using perl, you've
On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote:
> shemminger wrote:
>
> > It makes no sense to extend ethtool for something generic like that.
> > It shouldn't be that hard to do netlink in some richer scripting
> > language (like perl), but I haven't tried.
>
> If you're using perl, you've
shemminger wrote:
It makes no sense to extend ethtool for something generic like that.
It shouldn't be that hard to do netlink in some richer scripting
language (like perl), but I haven't tried.
If you're using perl, you've already given up performance, so just
parse /proc/net/dev.
I implemen
Roberto Nibali wrote:
+ * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h
+ * get_rx_all: Return 1 if set, 0 if not.
+ * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h
+ * get_save_fcs: Return 1 if set, 0 if not.
Something we would like to have in the standard kernel?
I'd love
On Wed, 2006-01-18 at 14:37 -0800, Ben Greear wrote:
> Roberto Nibali wrote:
> >>> It looks like the e1000 driver gathers all kinds of stats. How do I
> >>> access these from userspace?
> >>
> >>
> >> /proc/net/dev will have many of the common ones, and ethtool should
> >> get the rest.
> >>
> >>
Hmmm, most (if not all) of those you get using netlink, like so for
example:
ip -s -s link show dev eth0
But I see the incentive to add those to ethtool as well.
Yes, I think you can get everything out of netlink..but I find
the ethtool API much easier to use...
I envision one tool to confi
Roberto Nibali wrote:
Hmmm, most (if not all) of those you get using netlink, like so for
example:
ip -s -s link show dev eth0
But I see the incentive to add those to ethtool as well.
Yes, I think you can get everything out of netlink..but I find
the ethtool API much easier to use...
+ *
I'm manually pasting this out of my consolidated patch..it's against
2.6.15.
You should be able to ignore the send-to-self and crc related logic
w/out incident.
If this won't work, I can send you a link to my full patch, but it has a
lot
more than just this netdev stats hack in it
Thank
Roberto Nibali wrote:
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space to grab
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space to grab the netdev->stats struc
Christopher Friesen wrote:
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space t
16 matches
Mail list logo
