Re: netstat -i[d] violates PoLS
On Mon, Mar 31, 2014 at 10:03 PM, Alan Somers wrote: > "netstat -i" prints dropped output packets iff you also use "-d". > Starting with r199803 on 2009-11-25, "netstat -i" prints dropped input > packets regardless of the "-d" flags. That is a PoLS violation, IMHO. > I think that the "-d" flag should control printing of dropped input > packets as well as dropped output packets. I don't have any time to look into this, so please fix it as you prefer for the time being. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: fast bcopy...
2012/5/3, Steven Atreju : > K. Macy wrote [2012-05-03 02:58+0200]: >> It's highly chipset and processor dependent what works best. > > Yes, of course. > Though i was kinda, even shocked, once i've seen this first: > > http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 > > So we don't use our assembler version for new gccs and HAMMER or > SSE3+ (the decision for these was rather arbitrarily, except they > were yet existent for an instant implementation). > >> Intel now has non-temporal loads and stores which work much >> better in some cases but provide little benefit in others. > > Yes, our 2002 tests have shown that these were *extremely* > dependent upon alignment. (Note: 2002. o-) > Hmm, it doesn't really matter, but i guess this is a good time to > thank the FreeBSD hackers for that FPU stack FILD/FISTP idea! > I'll append the copy related notes of our doc/memperf.txt. > Thanks, I made an implementation of fpu unwinding and mmx copy to see if they were really making a difference years ago (reimplementing bcopy, memcopy, etc.). What really mattered with hw available at that time (pentium4) was the alignment and use of non-temporal operations on heavilly contended cache-lines. In few words it is more important we engineer the "buffer" layout rather than the functions themselves. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] Add MD5 signature checking for incoming packets
The patch at: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/tcp_signature/tcp_signature.diff - Enable the md5 signature checking for incoming packets, when both enabled in the kernel and desired by the socket - Spit out an error when the option TCP_SIGNATURE is enabled and IPSEC option is not (KPI usage problem, leading to just compiler error, in the current code) Some notes: - As suggested by bz@, I named the functions tcp_fields_to_net() and tcp_fields_to_host() just following the NetBSD's names - I add the statistic anyway to the tcpstats in order to avoid ABI breakage between kernel and modules/userland. Anyway it seems that tcpstats is not a member of any structure, so probabilly having them as last step could sitll make it conditional. I'm not entirely sure on what is the desired effect here, so I just included anyway, but I'm ready to change if someone makes a valid point The patch has been already reviewed by emaste and bz and tested for years on SVOS. Please cc' me for answers as I'm not really subscribed to -net@. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CFT/CFR, possible fix for ifconfig scan hang
2010/12/27 Bernhard Schmidt : > Hi, > > I recently received some complains about the infamous 'ifconfig scan hang' > issue again. Finally looking into that I noticed a bunch of inconsistences, > the most obvious one is that ifconfig(8) is talking about doing a background > scan by default, which is simply not true according to the implementation. > > Anyways.. the generic use-case which triggers the 'hang' is, if 'ifconfig > scan' is called while a scan is already in progress, net80211 will not start a > new one which means that no scan flags are updated, though, ifconfig will loop > until it receives a notification about the scan being done. This does always > happen after an 'ifconfig up', because net80211 will move the VAP into scan > state by default, with the scan flags set in such a way that a scan is done > until there is something to connect to. This also means that no notifications > about the scan being done are sent to upper layers, because the scan is not > finished.. > > If we successfully moved from scan to run state, how so ever, and now want to > call 'ifconfig scan' we're faced with another issue. Doing a scan while being > associated means we have to move off our current channel, to do this without > loosing any imported frames/information, we make use of the power save > feature. Now if we want to send any traffic while doing the scan, the scan is > temporary suspended, frames are sent, then the scan is restarted after > receiving a beacon and there is no frame to send. For this to work though, we > need to actually request a background scan so appropriate flags are set and > the scan is actually restarted. Without this, we hang until the bgscan timer > fires of at that next bgscanintval. > > I have a patch available which addresses both of the issues. It requests a > background scan by default and also honors the return value of > start_scan_locked(): > - for head > http://techwires.net/~bschmidt/scan_hang_head.diff > - for 8-stable/8.2-*: > http://techwires.net/~bschmidt/scan_hang_stable.diff > > Please test and let me know if it works, or not. Bernard, thanks a lot for working on this. There is any receipt for easilly reproduce this type of bug, or I should just go with 'ifconfig scan' repeteadly? I recall I could trigger it, but not 100% of times, so if you have more hints about how this problem could be reproduced, I'd be glad to hear. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] Netdump for review and testing -- preliminary version
2010/10/14 Robert N. M. Watson : > > On 14 Oct 2010, at 15:10, Attilio Rao wrote: > >>> My concern is less about occasional lost dumps that destabilising the >>> dumping process: calls into the memory allocator can currently trigger a >>> lot of interesting behaviours, such as further calls back into the VM >>> system, which can then trigger calls into other subsystems. What I'm >>> suggesting is that if we want the mbuf allocator to be useful in this >>> context, we need to teach it about things not to do in the dumping / crash >>> / ... context, which probably means helping uma out a bit in that regard. >>> And a watchdog to make sure the dump is making progress. >> >> I think that this would be way too complicated just to cope with panic >> within the VM/UMA (not sure what other subsystems you are referring >> to, wrt supposed to call). Besides, if we have a panic in the VM I'm >> sure that normal dumps could also be affected. >> When dealing with netdump, I'm not trying to fix all the bugs related >> to our dumping infrastructure because, as long as we already >> discussed, we know there are quite a few of them, but trying at least >> to follow the same fragile-ness than what we have today. >> And again, while I think the "watchdog" idea is good, I think it still >> applies to normal dumps too, it is not specific to netdump. > > No, what I'm saying is: UMA needs to not call its drain handlers, and ideally > not call into VM to fill slabs, from the dumping context. That's easy to > implement and will cause the dump to fail rather than causing the system to > hang. Ok. My point is, however, still the same: that should not happen just for the netdump specific case but for all the dumping/KDB/panic cases (I know it is unlikely current code !netdump calls into UMA but it is not an established pre-requisite and may still happen that some added code does). I still see this as a weakness on the infrastructure, independently from netdump. I can see that your point is that it is vital to netdump correct behaviour though, so I'd wonder if it worths fixing it now or later. More people's comment would be appreciated. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] Netdump for review and testing -- preliminary version
2010/10/14 Robert N. M. Watson : > > On 13 Oct 2010, at 18:46, Ryan Stone wrote: > >> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote: >>> + /* >>> + * get and fill a header mbuf, then chain data as an >>> extended >>> + * mbuf. >>> + */ >>> + MGETHDR(m, M_DONTWAIT, MT_DATA); >>> >>> The idea of calling into the mbuf allocator in this context is just freaky, >>> and may have some truly awful side effects. I suppose this is the cost of >>> trying to combine code paths in the network device driver rather than have >>> an independent path in the netdump case, but it's quite unfortunate and will >>> significantly reduce the robustness of netdumps in the face of, for example, >>> mbuf starvation. >> >> Changing this will require very invasive changes to the network >> drivers. I know that the Intel drivers allocate their own mbufs for >> their receive rings and I imagine that all other drivers have to do >> something similar. Plus the drivers are responsible for freeing mbufs >> after they have been transmitted. It seems to me that the cost of >> making significant changes to the network drivers to support an >> alternate lifecycle for netdump mbufs far outweighs the cost of losing >> a couple of kernel dumps in extreme circumstances. > > My concern is less about occasional lost dumps that destabilising the dumping > process: calls into the memory allocator can currently trigger a lot of > interesting behaviours, such as further calls back into the VM system, which > can then trigger calls into other subsystems. What I'm suggesting is that if > we want the mbuf allocator to be useful in this context, we need to teach it > about things not to do in the dumping / crash / ... context, which probably > means helping uma out a bit in that regard. And a watchdog to make sure the > dump is making progress. I think that this would be way too complicated just to cope with panic within the VM/UMA (not sure what other subsystems you are referring to, wrt supposed to call). Besides, if we have a panic in the VM I'm sure that normal dumps could also be affected. When dealing with netdump, I'm not trying to fix all the bugs related to our dumping infrastructure because, as long as we already discussed, we know there are quite a few of them, but trying at least to follow the same fragile-ness than what we have today. And again, while I think the "watchdog" idea is good, I think it still applies to normal dumps too, it is not specific to netdump. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] Netdump for review and testing -- preliminary version
2010/10/9 Robert Watson : > On Fri, 8 Oct 2010, Attilio Rao wrote: > >>> GENERAL FRAMEWORK ARCHITECTURE >>> >>> Netdump is composed, right now, by an userland "server" and a kernel >>> "client". The former is run on the target machine (where the dump will >>> phisically happen) and it is responsible for receiving the packets >>> containing coredumps frame and for correctly writing them on-disk. The >>> latter is part of the kernel installed on the source machine (where the dump >>> is initiated) and is responsible for building correctly UDP packets >>> containing the coredump frames, pushing through the network interface and >>> routing them appropriately. > > Hi Attilio: > > Network dumps would be a great addition to the FreeBSD debugging suite! A > few casual comments and questions, I need to spend some more time pondering > the implications of the current netdump design later in the week. > > (1) Did you consider using tftp as the network dump protocol, rather than a > custom protocol? It's also a simple UDP-based, ACKed file transfer > protocol, with the advantage that it's widely supported by exiting tftp > daemons, packet sniffers, security devices, etc. This wouldn't require > using a stock tftpd, although that would certainly be a benefit as well. > The post-processing of crashdumps that seems to happen in the netdump > server could, presumably, happen "offline" as easily...? I don't understand the "offline" question but, really, I don't know why tftp wasn't considered in the first place. Let me do some small search and see how much we could benefit from it. > (2) Have you thought about adding a checksum to the dump format, since > packets are going over the wire on UDP, etc? Even an MD5 sum wouldn't be > too hard to arrange: all the code is in the kernel already, requires > relatively little state storage, and is designed for streamed data. Someone else already brought this point and I agree, we could use a checksum here. > (3) As the bounds checking/etc behavior in dumping grows more complex, it > seems a shame to replicate it in architecture-specific code. Could we pull > the mediaoffset/mediasize checking into common code? Also, a reserved > size/offset of "0" meaning "no limit" sounds slightly worrying; it might be > slightly more conservative to add a flags field to dumperinfo and have a > flag indicating "size is no object" for netdump, rather than overloading the > existing fields. I don't agree with you here. The real problem is that dumpsys is highly disk-specific (I've commented about it somewhere, maybe the e-mail or maybe the commit logs). What we'd need is to have something like netdumpsys() which tries to use network, but it is not short to make and the mediasize+mediaoffset concept really rappresents an higher bound which can't be 0. I think it is a reasonable compromise so far but it is subjected to further improvements for sure. > Some specific patch comments: > > + * XXX: This should be split into machdep and non-machdep parts > > What MD parts are in the file? This is just a stale comment. > The sysctl parts of the patch have a number of issues: Sysctl are still not overhauled just because I'm not sure we want to keep them. That is one of the points I raised in the main e-mail and I'd really would like to hear opinions about if we should keep them rather than having a setup userland process, etc. I'm sorry about this, but please keep in mind that the file still needs a lot of cleanup so some comments are a bit out of date and other parts may not be still perfectly overhauled. > +sysctl_force_crash(SYSCTL_HANDLER_ARGS) > > Does this belong in the netdump code? We already have some of these options > in debug.kdb.*, but perhaps others should be added there as well. For this specific case, I'd really axe it out rather. > + /* > + * get and fill a header mbuf, then chain data as an > extended > + * mbuf. > + */ > + MGETHDR(m, M_DONTWAIT, MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freaky, > and may have some truly awful side effects. I suppose this is the cost of > trying to combine code paths in the network device driver rather than have > an independent path in the netdump case, but it's quite unfortunate and will > significantly reduce the robustness of netdumps in the face of, for example, > mbuf starvation. I'm not sure in which other way we could fix that actually. Maybe a pre-allocated pool of mbufs? > + if (ntohs(ah->ar_hrd) != ARPHRD_ETHE
Re: [PATCH] Netdump for review and testing -- preliminary version
2010/9/28 Attilio Rao : > In the last weeks I worked for porting the netdump infrastructure to > FreeBSD-CURRENT on the behalf of Sandvine Incorporated. > Netdump is a framework that aims for handling kernel coredumps over > the TCP/IP suite in order to dump to a separate machine than the > running one. That may be used on an interesting number of cases > involving disk-less workstations, disk driver debugging or embedded > devices. > > GENERAL FRAMEWORK ARCHITECTURE > > Netdump is composed, right now, by an userland "server" and a kernel > "client". The former is run on the target machine (where the dump will > phisically happen) and it is responsible for receiving the packets > containing coredumps frame and for correctly writing them on-disk. > The latter is part of the kernel installed on the source machine > (where the dump is initiated) and is responsible for building > correctly UDP packets containing the coredump frames, pushing through > the network interface and routing them appropriately. > > While the server may appear as, pretty much, a simple userland deamon > dealing with UDP packets, the client imposes interesting problems as > long as its activity is linked to handling kernel core dumping. More > precisely, as long as the client is part of the dumping mechanism and > the kernel may be in general panic conditions, netdump must ensure > "robustness" of operations. That is partially achieved by reworking > (and someway replicating) locally some UDP, ARP and IP operations, > hardsetting some values (like the default gateway, the destination and > the client address) and reducing further interactions with the kernel > just to the network interface acitivities. > More specifically, it implements a very basic UDP / IPv4 / ARP stack > separate from the standard stack (since that may not be in a > consistent state). > It can dump to a server on the same LAN or via a router (correctly > specifying the connection gateway). > In order to receive packet on critical conditions, netdump polls the > interface. Every network driver can implement hooks to be used by > netdump independently by DEVICE_POLLING option, even if it is > probabilly a good idea to share some code among them. The reference > set of hooks is contained into "struct netdump_methods". > And if_lem/if_em driver modifies may be set as reference for netdump > hooks implementation. > > In order to work into an "up and running" system (meant as with all > the devices in place) the netdump handler hooks as a pre-sync handler > (differently from other dumping routines). It however suffers some > problems typical of other dumping mechanism. For example, on DDB > entering unlocked version of polling handler is used, in order to > reduce the risk of deadlocks during inspections*. That reflects, among > the netdump methods, the existence of 2 versions of polling hooks, > where the "unlocked" is meant as reducing locking as much as possible. > > PATCH AND FURTHER WORK > > The patch is not totally complete and it is not intended to be > committed in SVN yet. What I'm looking for now is more testing and > review (in particular in terms of architecture) coverage by community. > The server should be in realtively "committable" state, though, but I > encourage its stress-testing. A manpage is provided along that should > be very easy to understand how to use it. > > Things that can be further improved, as it is now, in the client, are: > - Deciding if hardcoding of the kernel parameter is done properly. I > personally don't like the sysctl usage and I would prefer an userland > small utility used to testing and maybe add some tunables for enabling > netdump early in the boot. You may have several opinions on this > though. > - VIMAGE and IPv6 support. > - More drivers support. Right now only if_em (and if_lem) are > converted to use netdump and can be used as a draft for other device > drivers. if_ixgb should came along in the final, committing, version > too. In general I think that all drivers supporting device polling > could easilly support also netdump > - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It > should be made, instead, more neutral and more flexible to cope better > with different interfaces. It is a quite a bit of work, however, and > beyond the scope of netdump introduction (even if it could be > beneficial for it) > > Netdump has been developed on a FreeBSD project branch located here: > svn://svn.freebsd.org/base/projects/sv/ > > which could also forsee further informations about every single > change. However, for your convenience, also a patch has been made > public which is locate
Re: [PATCH] Netdump for review and testing -- preliminary version
2010/9/29 Sergey Kandaurov : > [just don't know what namely need to test, so] > > All made according to your instructions. > The only way I could trigger netdump was > to run its ddb command by hand. Neither > debug.kdb.enter nor debug.kdb.panic don't do it. You probabilly need to use KDB_UNATTENDED. > Some numbers and output (bit verbose > but again don't know what need to show here) > Entered through debug.kdb.panic, thus Panicstring. > db> netdump > > --- > netdump in progress. searching for server.. dumping to xx.xxx.xx.xx > (00:1a:64:d3:4f:20) > --- > Physical memory: 2026 MB > Dumping 1154 MB: 1139 1123 1107 1091 1075 1059 1043 1027 1011 995 979 > 963 947 931 915 899 883 867 851 835 819 803 787 771 755 739 723 707 > 691 675 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 > 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 > 147 131 115 99 83 67 51 35 19 3 > Dump complete > > netdump finished. > cancelling normal dump > > # ls -hl /home/fooserv/crash/ > total 1182930 > -rw-r--r-- 1 root wheel 404B Sep 29 12:05 info.fooserv.0 > -rw-r--r-- 1 root wheel 1.1G Sep 29 12:05 vmcore.fooserv.0 > > Dump from fooserv [xx.xxx.xx.xx] > Architecture: amd64 > Architecture version: 2 > Dump length: 1210687488B (1154 MB) > blocksize: 8192 > Dumptime: Wed Sep 29 11:55:30 2010 > Hostname: fooserv > Versionstring: FreeBSD 9.0-CURRENT #51: Wed Sep 29 07:18:24 UTC 2010 > r...@fooserv:/usr/obj/usr/src/sys/GENERIC > Panicstring: kdb_sysctl_panic > Header parity check: Pass > Dump complete > > I tried to netdump a bit later again, but it couldn't find server, which > runs though, and client traffic was seen on server-side (w/o reply). > db> netdump > > --- > netdump in progress. searching for server.. . . . . . . . . . . . > Failed to contact netdump server Could you compile the kernel with NETDUMP_CLIENT_DEBUG and retry? (Warning: the log may be huge, so you may be needing to log with serial line) I will try to reproduce locally, if anything. Thanks, Attilio > > As for netdumpserv, > it misses #include before __FBSDID(); > I happily tested it on 7.3-amd64. Yes, there are also other small style(9) nits that needs to be addressed in the netdumpserver as well. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] Netdump for review and testing -- preliminary version
In the last weeks I worked for porting the netdump infrastructure to FreeBSD-CURRENT on the behalf of Sandvine Incorporated. Netdump is a framework that aims for handling kernel coredumps over the TCP/IP suite in order to dump to a separate machine than the running one. That may be used on an interesting number of cases involving disk-less workstations, disk driver debugging or embedded devices. GENERAL FRAMEWORK ARCHITECTURE Netdump is composed, right now, by an userland "server" and a kernel "client". The former is run on the target machine (where the dump will phisically happen) and it is responsible for receiving the packets containing coredumps frame and for correctly writing them on-disk. The latter is part of the kernel installed on the source machine (where the dump is initiated) and is responsible for building correctly UDP packets containing the coredump frames, pushing through the network interface and routing them appropriately. While the server may appear as, pretty much, a simple userland deamon dealing with UDP packets, the client imposes interesting problems as long as its activity is linked to handling kernel core dumping. More precisely, as long as the client is part of the dumping mechanism and the kernel may be in general panic conditions, netdump must ensure "robustness" of operations. That is partially achieved by reworking (and someway replicating) locally some UDP, ARP and IP operations, hardsetting some values (like the default gateway, the destination and the client address) and reducing further interactions with the kernel just to the network interface acitivities. More specifically, it implements a very basic UDP / IPv4 / ARP stack separate from the standard stack (since that may not be in a consistent state). It can dump to a server on the same LAN or via a router (correctly specifying the connection gateway). In order to receive packet on critical conditions, netdump polls the interface. Every network driver can implement hooks to be used by netdump independently by DEVICE_POLLING option, even if it is probabilly a good idea to share some code among them. The reference set of hooks is contained into "struct netdump_methods". And if_lem/if_em driver modifies may be set as reference for netdump hooks implementation. In order to work into an "up and running" system (meant as with all the devices in place) the netdump handler hooks as a pre-sync handler (differently from other dumping routines). It however suffers some problems typical of other dumping mechanism. For example, on DDB entering unlocked version of polling handler is used, in order to reduce the risk of deadlocks during inspections*. That reflects, among the netdump methods, the existence of 2 versions of polling hooks, where the "unlocked" is meant as reducing locking as much as possible. PATCH AND FURTHER WORK The patch is not totally complete and it is not intended to be committed in SVN yet. What I'm looking for now is more testing and review (in particular in terms of architecture) coverage by community. The server should be in realtively "committable" state, though, but I encourage its stress-testing. A manpage is provided along that should be very easy to understand how to use it. Things that can be further improved, as it is now, in the client, are: - Deciding if hardcoding of the kernel parameter is done properly. I personally don't like the sysctl usage and I would prefer an userland small utility used to testing and maybe add some tunables for enabling netdump early in the boot. You may have several opinions on this though. - VIMAGE and IPv6 support. - More drivers support. Right now only if_em (and if_lem) are converted to use netdump and can be used as a draft for other device drivers. if_ixgb should came along in the final, committing, version too. In general I think that all drivers supporting device polling could easilly support also netdump - Ideally dumpsys() in FreeBSD is too much disk-activity oriented. It should be made, instead, more neutral and more flexible to cope better with different interfaces. It is a quite a bit of work, however, and beyond the scope of netdump introduction (even if it could be beneficial for it) Netdump has been developed on a FreeBSD project branch located here: svn://svn.freebsd.org/base/projects/sv/ which could also forsee further informations about every single change. However, for your convenience, also a patch has been made public which is located here (against freebsd-curr...@213246): http://www.freebsd.org/~attilio/Sandvine/STABLE_8/netdump/netdump_alpha_0.diff In order to enable the client it is enough to add at your kernel config: optionsNETDUMP_CLIENT NETDUMP_CLIENT_DEBUG can be specified too in order to have further debuggin traces but I'd encourage to use them just for developing Netdump itself. TYPICAL USAGE This is a set of the available sysctls for netdump: # sysctl -d net.dump net.dump: netdump net.dump.enable: enable network dump n
Re: [PATCH] Add idrop report to netstat
2009/11/17 Pyun YongHyeon :
> On Mon, Nov 16, 2009 at 11:04:20PM +0100, Attilio Rao wrote:
>> 2009/11/16 Pyun YongHyeon :
>> > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote:
>> >> [Please CC me as I'm not subscribed to -...@]
>> >>
>> >> This patch allows to show the informations about packets droped on
>> >> input for interfaces on netstat:
>> >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff
>> >>
>> >> This patch as been contributed back from Sandvine Incorporated.
>> >> Comments, reviews and testing are welcome.
>> >>
>> >
>> > Doesn't -d of netstat(1) show the same information?
>>
>> Am I wrong or "-d" prints the drops on the output path?
>> The patch provides information on the input drops.
>>
>
> struct if_data {
>/* generic interface information */
>u_char ifi_type; /* ethernet, tokenring, etc */
>u_char ifi_physical; /* e.g., AUI, Thinnet, 10base-T, etc */
> [...]
>u_long ifi_iqdrops;/* dropped on input, this interface */
>
>
>u_long ifi_noproto;/* destined for unsupported protocol */
>u_long ifi_hwassist; /* HW offload capabilities, see IFCAP
> */
>time_t ifi_epoch; /* uptime at attach or stat reset */
>struct timeval ifi_lastchange; /* time of last administrative change
> */
> };
Err, but dflag does print out if_snd.ifq_drops. Infact:
@if.c:sidewaysintpr()
[...]
if (!first) {
show_stat("lu", 10, ifnet.if_ipackets - ip->ift_ip, 1);
show_stat("lu", 5, ifnet.if_ierrors - ip->ift_ie, 1);
show_stat("lu", 10, ifnet.if_ibytes - ip->ift_ib, 1);
show_stat("lu", 10, ifnet.if_opackets - ip->ift_op, 1);
show_stat("lu", 5, ifnet.if_oerrors - ip->ift_oe, 1);
show_stat("lu", 10, ifnet.if_obytes - ip->ift_ob, 1);
show_stat("NRSlu", 5,
ifnet.if_collisions - ip->ift_co, 1);
if (dflag)
show_stat("LSu", 5,
ifnet.if_snd.ifq_drops - ip->ift_dr, 1);
}
[...]
if (!first) {
show_stat("lu", 10, sum->ift_ip - total->ift_ip, 1);
show_stat("lu", 5, sum->ift_ie - total->ift_ie, 1);
show_stat("lu", 10, sum->ift_ib - total->ift_ib, 1);
show_stat("lu", 10, sum->ift_op - total->ift_op, 1);
show_stat("lu", 5, sum->ift_oe - total->ift_oe, 1);
show_stat("lu", 10, sum->ift_ob - total->ift_ob, 1);
show_stat("NRSlu", 5, sum->ift_co - total->ift_co, 1);
if (dflag)
show_stat("LSu", 5,
sum->ift_dr - total->ift_dr, 1);
}
Which is defined in sys/net/if_var.h as:
struct ifnet {
void*if_softc; /* pointer to driver state */
void*if_l2com; /* pointer to protocol bits */
struct vnet *if_vnet; /* pointer to network stack instance */
[...]
int if_drv_flags; /* driver-managed status flags */
struct ifaltq if_snd; /* output queue (includes altq) */
const u_int8_t *if_broadcastaddr; /* linklevel broadcast bytestring */
[...]
};
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] Add idrop report to netstat
2009/11/16 Pyun YongHyeon : > On Mon, Nov 16, 2009 at 04:15:09PM +0100, Attilio Rao wrote: >> [Please CC me as I'm not subscribed to -...@] >> >> This patch allows to show the informations about packets droped on >> input for interfaces on netstat: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff >> >> This patch as been contributed back from Sandvine Incorporated. >> Comments, reviews and testing are welcome. >> > > Doesn't -d of netstat(1) show the same information? Am I wrong or "-d" prints the drops on the output path? The patch provides information on the input drops. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] Add idrop report to netstat
[Please CC me as I'm not subscribed to -...@] This patch allows to show the informations about packets droped on input for interfaces on netstat: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/idrops/idrops.diff This patch as been contributed back from Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] Fix a socket leak in libfetch
[Please CC me as I'm not subscribed to -...@] In ftp_request(), after a successfully established connection, subsequent errors can bring to a socket leak. This patch should fix that: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/libfetch/ftp.diff This patch has been contributed back by Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[PATCH] libtacplus bugfix
[Please CC me as I'm not subscribed to -...@] In tac_get_av_value() empty attributes should be handled like 0-lenght strings while in the current code they are handled as unset attributes. This patch implements the (probabilly) desired semantic: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/libtacplus/taclib.diff This patch has been contributed back by Sandvine Incorporated. Comments, reviews and testing are welcome. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
2009/4/23 Ed Maste : > On Fri, Mar 27, 2009 at 11:05:00AM +, Andrew Brampton wrote: > >> 2009/3/27 Luigi Rizzo : >> > The load of polling is pretty low (within 1% or so) even with >> > polling. The advantage of having interrupts is faster response >> > to incoming traffic, not CPU load. >> >> oh, I was under the impression that polling spun in a tight loop, thus >> using 100% of the processor. After a quick test I see this is not the >> case. I assume it will get to 100% CPU load if I saturate my network. > > Yes, polling has a limit on the maximum CPU time it will use, and also > will use less than the limit if there is no traffic. > > There are a number of sysctls under kern.polling that control its > behaviour: > > * kern.polling.user_frac: Desired user fraction of cpu time > > This attempts to reserve at least a specified percentage of available > CPU time for user processes; polling tries to limit its percentage use > to 100 less this value. > > * kern.polling.burst: Current polling burst size > * kern.polling.burst_max: Max Polling burst size > * kern.polling.each_burst: Max size of each burst > > These three control the number of packets that polling processes per > call / tick. Packets are processed in batches of each_burst, up to > burst packets total per tick. The value of burst is capped at > busrt_max. > > In order to keep the user_frac CPU percentage available for non-polling, > a feedback loop is used that controls the value of burst. Each time a > bach of packets is processed, burst is incremented or decremented by 1, > depending on how much CPU time polling actually used. In addition, if > polling extends beyond the next tick it's scaled back to 7/8ths of the > current value. > > Polling was originally implemented as a livelock-avoidance technique > for the single-core case -- the primary goal is to guarantee the > availability of CPU time specified in user_frac. The current algorithm > does not behave that well if user_frac is set low. Setting it low is > reasonable if the workload is largely in-kernel (i.e., bridging or > routing), or when running SMP. > > Another downside of the current implementation is that interfaces will > be polled multiple times per tick (burst / each_burst times), even if > there are no packets to process. > > At work we've developed a replacement polling algorithm that keeps track > of the actual amount of time spent per packet, and uses that as the > feedback to control the number of packets in each batch. > > This work requires a change to the polling KPI: the polling handlers > have to return the count of packets actually handled. My hope is to get > the KPI change committed in time for 8.0, even if we don't switch the > algorithm yet. Attilio (on CC:) and I will make the patch set for the > KPI change available shortly for comment. This is the KPI breakage patch: http://people.freebsd.org/~attilio/Sandvine/polling/polling_kpi.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: New wpi driver
First of all, WPI_PCI_BAR0 might not be defined in this way, but it should really use PCIR_BAR() macro. Then, probabilly, gabor's device I/O space is relative to another BAR, so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it does allocate. Sorry, n ranges 0-5... (as I said before 6 different address spaces). Today it seems I'm absolutely sleeping... (probabilly I'm too angry to have not parecipied at EuroBSDCon...). Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: 2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: > 2006/11/10, Max Laier <[EMAIL PROTECTED]>: > > On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > > > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > > > Unfortunately, it seems that this is still that unfinished driver from > > > > Damien, that circulates on the net everywhere, but it only works for > > > > some lucky people. As for me, I get an error message when loading the > > > > module, that it could not allocate resources. > > > > > > I don't think it's "that unfinished driver from Damien" classify it > > > correctly, as stated it's an unsupported version so case where it will > > > not work are expected. Feel free to improve it or wait when some FreeBSD > > > developer will port and maintain it. > > > > I agree. On top of that, a more detailed error report would be preferable. > > From what you put above, it seems that you are out of sufficient continous > > memory at the point where you enable the hardware. Try enabling it before > > bringing up X11 etc. > > Even if I'm not totally aware about what problem are gabor@ is having > at the moment, some time ago I started looking at the code and one > difference between ipi and wpi is in rings they use (and their > allocation) and again in the usage of a shared DMA memory page between > the host and the NIC. s/ipi/iwi. Ok I gave a quick look at the code and gabor@ problem is about memory-mapped I/O resource allocation. First of all, WPI_PCI_BAR0 might not be defined in this way, but it should really use PCIR_BAR() macro. Then, probabilly, gabor's device I/O space is relative to another BAR, so simply try all 6 using PCIR_BAR(n) where n range is 0-6 until it does allocate. Attilio PS: I would like that the code will better follow stlye(9) too... -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Attilio Rao <[EMAIL PROTECTED]>: 2006/11/10, Max Laier <[EMAIL PROTECTED]>: > On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > > Unfortunately, it seems that this is still that unfinished driver from > > > Damien, that circulates on the net everywhere, but it only works for > > > some lucky people. As for me, I get an error message when loading the > > > module, that it could not allocate resources. > > > > I don't think it's "that unfinished driver from Damien" classify it > > correctly, as stated it's an unsupported version so case where it will > > not work are expected. Feel free to improve it or wait when some FreeBSD > > developer will port and maintain it. > > I agree. On top of that, a more detailed error report would be preferable. > From what you put above, it seems that you are out of sufficient continous > memory at the point where you enable the hardware. Try enabling it before > bringing up X11 etc. Even if I'm not totally aware about what problem are gabor@ is having at the moment, some time ago I started looking at the code and one difference between ipi and wpi is in rings they use (and their allocation) and again in the usage of a shared DMA memory page between the host and the NIC. s/ipi/iwi. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New wpi driver
2006/11/10, Max Laier <[EMAIL PROTECTED]>: On Friday 10 November 2006 10:37, Massimo Lusetti wrote: > On Thu, 2006-11-09 at 22:39 +0100, Gábor Kövesdán wrote: > > Unfortunately, it seems that this is still that unfinished driver from > > Damien, that circulates on the net everywhere, but it only works for > > some lucky people. As for me, I get an error message when loading the > > module, that it could not allocate resources. > > I don't think it's "that unfinished driver from Damien" classify it > correctly, as stated it's an unsupported version so case where it will > not work are expected. Feel free to improve it or wait when some FreeBSD > developer will port and maintain it. I agree. On top of that, a more detailed error report would be preferable. From what you put above, it seems that you are out of sufficient continous memory at the point where you enable the hardware. Try enabling it before bringing up X11 etc. Even if I'm not totally aware about what problem are gabor@ is having at the moment, some time ago I started looking at the code and one difference between ipi and wpi is in rings they use (and their allocation) and again in the usage of a shared DMA memory page between the host and the NIC. Maybe this is not done in the right way in the Damien's driver and this is beacause gabor would having allocation problems. Attilio PS: I will try to look at the code posted above ASAP... -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
