Re: cloneable tun
On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: From: Mike Belopuhov m...@belopuhov.com Date: Wed, 28 Nov 2012 22:21:07 +0100 On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Wed, 28 Nov 2012 17:39:24 +0100 From: Reyk Floeter r...@openbsd.org Hi, inspired by mikeb@'s clonable bpf patch, this slightly more complex diff implements clonable interface support to tun(4). The idea is to split the fixed relation between device minor number (/dev/tunX) and interface unit (ifconfig tunY). In difference to the current tun(4) implementation, opening /dev/tun0 will first do nothing and return an unuseable device. You first have to call the new TUNSIFUNIT to assign/request a specified interface unit. Why? Because people don't realize they need to run MAKEDEV to get more than four tun(4) devices? Drawback: This diff would require to patch all the existing users of /dev/tun* in ports and the tree to add the TUNSIFUNIT ioctl. The benefit is that you don't have to MAKEDEV all the tuns anymore and can open up to around 1024 active tun(4) interfaces (with the specinfo patch). That's a pretty big drawback. third party software has to be patched anyways, since tun is not standard. But currently /dev/tunN is usable from any programming language that that can do reads and writes. With Reyk's changes you need to do an ioctl even for basic usage, which is at best quirky in languages other than C/C++. That feels like a step backward to me. sure, we can totally leave tun for legacy use in the shell scripts. so i guess reyk should go ahead and implement a dynamic tun interface (dun?) with whatever semantics we need and want.
Fix MacBook Air 2010 speakers
Adapted from
http://marc.info/?l=openbsd-miscm=128919130029011w=2
OK?
Index: dev/pci/azalia_codec.c
===
RCS file: /home/cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.151
diff -u -p -r1.151 azalia_codec.c
--- dev/pci/azalia_codec.c 10 Sep 2010 15:11:23 - 1.151
+++ dev/pci/azalia_codec.c 29 Nov 2012 11:16:41 -
@@ -64,6 +64,13 @@ azalia_codec_init_vtbl(codec_t *this)
this-name = NULL;
this-qrks = AZ_QRK_NONE;
switch (this-vid) {
+ case 0x10134206:
+ this-name = Cirrus Logic CS4206;
+ if (this-subid == 0xcb8910de) {/* APPLE_MBA3_1 */
+ this-qrks |= AZ_QRK_GPIO_UNMUTE_1 |
+ AZ_QRK_GPIO_UNMUTE_3;
+ }
+ break;
case 0x10ec0260:
this-name = Realtek ALC260;
break;
@@ -2403,6 +2410,9 @@ azalia_codec_gpio_quirks(codec_t *this)
}
if (this-qrks AZ_QRK_GPIO_UNMUTE_2) {
azalia_gpio_unmute(this, 2);
+ }
+ if (this-qrks AZ_QRK_GPIO_UNMUTE_3) {
+ azalia_gpio_unmute(this, 3);
}
return(0);
Re: cloneable tun
On 2012/11/28 22:21, Mike Belopuhov wrote: Drawback: This diff would require to patch all the existing users of /dev/tun* in ports and the tree to add the TUNSIFUNIT ioctl. The benefit is that you don't have to MAKEDEV all the tuns anymore and can open up to around 1024 active tun(4) interfaces (with the specinfo patch). That's a pretty big drawback. third party software has to be patched anyways, since tun is not standard. The non-standard parts with the existing interface are mostly to do with configuration (in practice most third-party software e.g. openvpn, openconnect just calls out to ifconfig for that) and device node naming..
Re: cloneable tun
On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov m...@belopuhov.com wrote:
But currently /dev/tunN is usable from any programming language that
that can do reads and writes. With Reyk's changes you need to do an
ioctl even for basic usage, which is at best quirky in languages other
than C/C++. That feels like a step backward to me.
sure, we can totally leave tun for legacy use in the shell scripts.
so i guess reyk should go ahead and implement a dynamic tun interface
(dun?) with whatever semantics we need and want.
Or even better duh? ;-) I wrote this diff because I wanted to
experiment with clonable device nodes, I still don't like the fact
that you have to MAKEDEV a device per dynamic interface, and because
it adds some extra flexibility. But it doesn't have to go anywhere, I
didn't even waste much time with writing it yesterday in the
afternoon.
btw., I like C and it is still my favorite language (sorry, CS
people). But it shouldn't be a problem to do simple ioctls with most
other languages except shell scripts.
#!/usr/bin/perl
require sys/ioctl.ph;
$TUNSIFUNIT = _IOC(IOC_INOUT, ord('t'), 90, 4);
open(TUN0, +/dev/tun0) or die open;
ioctl(TUN0, $TUNSIFUNIT, $unit = pack(i, -1)) or die ioctl $!;
print Returned: tun.unpack(i, $unit).\n;
close(TUN0);
reyk
Re: cloneable tun
On Thu, Nov 29, 2012 at 01:33:47PM +0100, Reyk Floeter wrote:
On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov m...@belopuhov.com wrote:
But currently /dev/tunN is usable from any programming language that
that can do reads and writes. With Reyk's changes you need to do an
ioctl even for basic usage, which is at best quirky in languages other
than C/C++. That feels like a step backward to me.
sure, we can totally leave tun for legacy use in the shell scripts.
so i guess reyk should go ahead and implement a dynamic tun interface
(dun?) with whatever semantics we need and want.
Or even better duh? ;-) I wrote this diff because I wanted to
experiment with clonable device nodes, I still don't like the fact
that you have to MAKEDEV a device per dynamic interface, and because
it adds some extra flexibility. But it doesn't have to go anywhere, I
didn't even waste much time with writing it yesterday in the
afternoon.
btw., I like C and it is still my favorite language (sorry, CS
people). But it shouldn't be a problem to do simple ioctls with most
other languages except shell scripts.
#!/usr/bin/perl
require sys/ioctl.ph;
$TUNSIFUNIT = _IOC(IOC_INOUT, ord('t'), 90, 4);
open(TUN0, +/dev/tun0) or die open;
ioctl(TUN0, $TUNSIFUNIT, $unit = pack(i, -1)) or die ioctl $!;
print Returned: tun.unpack(i, $unit).\n;
close(TUN0);
Any decent language will have ioctl support...
Proof: perl does :)
Re: cloneable tun
On 11/29/2012 01:33 PM, Reyk Floeter wrote:
On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov m...@belopuhov.com wrote:
But currently /dev/tunN is usable from any programming language that
that can do reads and writes. With Reyk's changes you need to do an
ioctl even for basic usage, which is at best quirky in languages other
than C/C++. That feels like a step backward to me.
sure, we can totally leave tun for legacy use in the shell scripts.
so i guess reyk should go ahead and implement a dynamic tun interface
(dun?) with whatever semantics we need and want.
Or even better duh? ;-) I wrote this diff because I wanted to
experiment with clonable device nodes, I still don't like the fact
that you have to MAKEDEV a device per dynamic interface, and because
it adds some extra flexibility. But it doesn't have to go anywhere, I
didn't even waste much time with writing it yesterday in the
afternoon.
btw., I like C and it is still my favorite language (sorry, CS
people). But it shouldn't be a problem to do simple ioctls with most
other languages except shell scripts.
#!/usr/bin/perl
require sys/ioctl.ph;
$TUNSIFUNIT = _IOC(IOC_INOUT, ord('t'), 90, 4);
open(TUN0, +/dev/tun0) or die open;
ioctl(TUN0, $TUNSIFUNIT, $unit = pack(i, -1)) or die ioctl $!;
print Returned: tun.unpack(i, $unit).\n;
close(TUN0);
reyk
I like cloning devices. But instead of needing an ioclt(2), wouldn't
it be simpler to adapt the SVR4 API where the first parameter of
cdevsw open() functions is an 'dev_t *dev'. Thus the open() routine
can automatically do the cloning (or maybe not if minor is 0) by
returning the device-Id of the cloned instance. and there is no need
for using additional ioctl(2)s.
Of course it requires a one-time API change with large impact.
Gerhard
Re: X540T: link is not detected
On Wed, Nov 28, 2012 at 12:38 PM, mxb m...@alumni.chalmers.se wrote: Compiling if_ix.c with IX_DEBUG yields ../../../../dev/pci/if_ix.c: In function 'ixgbe_print_hw_stats': ../../../../dev/pci/if_ix.c:3525: error: 'struct ix_softc' has no member named 'mbuf_alloc_failed' ../../../../dev/pci/if_ix.c:3526: error: 'struct ix_softc' has no member named 'mbuf_cluster_failed' According to the if_ix.h those two are gone. Diff to fix it. i've committed a somewhat similar diff. thanks.
Re: set ifp-if_baudrate with IF_Gbps() / IF_Mbps()
On Wed, Nov 28, 2012 at 2:25 AM, Brad Smith b...@comstyle.com wrote: On Sat, Nov 24, 2012 at 10:24:00PM -0500, Brad Smith wrote: On Fri, Nov 23, 2012 at 11:57:50AM -0200, Gleydson Soares wrote: set ifp-if_baudrate with IF_Gbps() / IF_Mbps(). OK ? Although it has already been commited its the wrong direction to go in. These should be removed as the MII framework deals with this properly, plus you missed a bunch of drivers. An updated diff now that the other bits have been commited. OK? Please note that pfctl/altq has a bug where bandwidth specification expressed in percentage gets converted to the absolute value when pfctl is run. And since for some NICs in some setups it might take some time to acquire a link this would mean that when pfctl is run right after netstart (like in /etc/rc), bandwidth calculation will be wrong. Since your diff doesn't exactly make the situation worse, as you might end up with a wrong bandwidth anyways, I'm OK with it.
Re: set ifp-if_baudrate with IF_Gbps() / IF_Mbps()
On Thu, Nov 29, 2012 at 3:12 PM, Mike Belopuhov m...@belopuhov.com wrote: OK? Please note that pfctl/altq has a bug where bandwidth specification expressed in percentage gets converted to the absolute value when pfctl is run. And since for some NICs in some setups it might take some time to acquire a link this would mean that when pfctl is run right after netstart (like in /etc/rc), bandwidth calculation will be wrong. Since your diff doesn't exactly make the situation worse, as you might end up with a wrong bandwidth anyways, I'm OK with it. Yes, I'm also OK with the diff because we can at least expect the same behavior everywhere now. ALTQ should calculate and update the relative bandwidth in the kernel, but this is another thing and would probably conflict with henning's work on the new queuing subsystem. Reyk
change if_iqdrops to if_ierrors
hi,
drivers ex age alc ale jme se vic vte xe upl and octeon/cmac
make use of the if_iqdrops counter that is not shown by any of our
tools (like netstat). looks like most of its usage comes from
freebsd where they show it in the netstat -di output in a new
column. do we want to do that or just convert them to if_ierrors
since 90% of our drivers do only if_ierrors. there's also doesn't
seem to be any rule when to use if_iqdrops (well, since in most
drivers there's no input queueing -- check out upl(4) :)
the diff below changes all the drivers in our tree to use
if_ierrors instead of if_iqdrops. i've decided to leave
octeon/cmac driver as is because if_iqdrops is used for
debugging purposes there.
ack? nack? meh?
diff --git sys/dev/isa/if_ex.c sys/dev/isa/if_ex.c
index 49eb077..f93165f 100644
--- sys/dev/isa/if_ex.c
+++ sys/dev/isa/if_ex.c
@@ -661,7 +661,7 @@ ex_rx_intr(struct ex_softc *sc)
MGETHDR(m, M_DONTWAIT, MT_DATA);
ipkt = m;
if (ipkt == NULL)
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
else {
ipkt-m_pkthdr.rcvif = ifp;
ipkt-m_pkthdr.len = pkt_len;
@@ -673,7 +673,7 @@ ex_rx_intr(struct ex_softc *sc)
m-m_len = MCLBYTES;
else {
m_freem(ipkt);
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
goto rx_another;
}
}
@@ -696,7 +696,7 @@ ex_rx_intr(struct ex_softc *sc)
MT_DATA);
if (m-m_next == NULL) {
m_freem(ipkt);
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
goto rx_another;
}
m = m-m_next;
diff --git sys/dev/pci/if_age.c sys/dev/pci/if_age.c
index f5f6de5..53903c1 100644
--- sys/dev/pci/if_age.c
+++ sys/dev/pci/if_age.c
@@ -1329,7 +1329,7 @@ age_rxeof(struct age_softc *sc, struct rx_rdesc *rxrd)
desc = rxd-rx_desc;
/* Add a new receive buffer to the ring. */
if (age_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse Rx buffers. */
if (sc-age_cdata.age_rxhead != NULL) {
m_freem(sc-age_cdata.age_rxhead);
diff --git sys/dev/pci/if_alc.c sys/dev/pci/if_alc.c
index eac4148..ef22bb5 100644
--- sys/dev/pci/if_alc.c
+++ sys/dev/pci/if_alc.c
@@ -1952,7 +1952,7 @@ alc_rxeof(struct alc_softc *sc, struct rx_rdesc *rrd)
mp = rxd-rx_m;
/* Add a new receive buffer to the ring. */
if (alc_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse Rx buffers. */
if (sc-alc_cdata.alc_rxhead != NULL)
m_freem(sc-alc_cdata.alc_rxhead);
diff --git sys/dev/pci/if_ale.c sys/dev/pci/if_ale.c
index 1e5004e..ef6348f 100644
--- sys/dev/pci/if_ale.c
+++ sys/dev/pci/if_ale.c
@@ -1552,7 +1552,7 @@ ale_rxeof(struct ale_softc *sc)
m = m_devget((char *)(rs + 1), length - ETHER_CRC_LEN,
ETHER_ALIGN, ifp, NULL);
if (m == NULL) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
ale_rx_update_page(sc, rx_page, length, prod);
continue;
}
diff --git sys/dev/pci/if_jme.c sys/dev/pci/if_jme.c
index 25c954f..37a1efa 100644
--- sys/dev/pci/if_jme.c
+++ sys/dev/pci/if_jme.c
@@ -1602,7 +1602,7 @@ jme_rxpkt(struct jme_softc *sc)
/* Add a new receive buffer to the ring. */
if (jme_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse buffer. */
jme_discard_rxbufs(sc, cons, nsegs - count);
if (sc-jme_cdata.jme_rxhead != NULL) {
diff --git sys/dev/pci/if_se.c sys/dev/pci/if_se.c
index 1c75288..b2206ae 100644
--- sys/dev/pci/if_se.c
+++ sys/dev/pci/if_se.c
@@ -947,7 +947,7 @@ se_rxeof(struct se_softc *sc)
m = cd-se_rx_mbuf[i];
if (se_newbuf(sc, i) != 0) {
Re: set ifp-if_baudrate with IF_Gbps() / IF_Mbps()
* Reyk Floeter r...@openbsd.org [2012-11-29 15:31]: On Thu, Nov 29, 2012 at 3:12 PM, Mike Belopuhov m...@belopuhov.com wrote: Please note that pfctl/altq has a bug where bandwidth specification expressed in percentage gets converted to the absolute value when pfctl is run. And since for some NICs in some setups it might take some time to acquire a link this would mean that when pfctl is run right after netstart (like in /etc/rc), bandwidth calculation will be wrong. Since your diff doesn't exactly make the situation worse, as you might end up with a wrong bandwidth anyways, I'm OK with it. Yes, I'm also OK with the diff because we can at least expect the same behavior everywhere now. ALTQ should calculate and update the relative bandwidth in the kernel, but this is another thing and would probably conflict with henning's work on the new queuing subsystem. fwiw, I don't have relative implemented yet for the new one; my plan is to polish it now so that it can go in (without removing altq yet) and add the relative specs and a few rather minor bits in-tree - of course with dynamically updated bandwidths. the altq side isn't easily fixable, pfctl does relative - absolute conversions, the kernel has no idea what used to be a relative spec. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: change if_iqdrops to if_ierrors
On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote:
hi,
drivers ex age alc ale jme se vic vte xe upl and octeon/cmac
make use of the if_iqdrops counter that is not shown by any of our
tools (like netstat). looks like most of its usage comes from
freebsd where they show it in the netstat -di output in a new
column. do we want to do that or just convert them to if_ierrors
since 90% of our drivers do only if_ierrors. there's also doesn't
seem to be any rule when to use if_iqdrops (well, since in most
drivers there's no input queueing -- check out upl(4) :)
the diff below changes all the drivers in our tree to use
if_ierrors instead of if_iqdrops. i've decided to leave
octeon/cmac driver as is because if_iqdrops is used for
debugging purposes there.
ack? nack? meh?
Seems like a good idea to me to not lose those errors. I have
no great desire for a new column in netstat, but no great
antagonism to one either.
Ken
diff --git sys/dev/isa/if_ex.c sys/dev/isa/if_ex.c
index 49eb077..f93165f 100644
--- sys/dev/isa/if_ex.c
+++ sys/dev/isa/if_ex.c
@@ -661,7 +661,7 @@ ex_rx_intr(struct ex_softc *sc)
MGETHDR(m, M_DONTWAIT, MT_DATA);
ipkt = m;
if (ipkt == NULL)
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
else {
ipkt-m_pkthdr.rcvif = ifp;
ipkt-m_pkthdr.len = pkt_len;
@@ -673,7 +673,7 @@ ex_rx_intr(struct ex_softc *sc)
m-m_len = MCLBYTES;
else {
m_freem(ipkt);
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
goto rx_another;
}
}
@@ -696,7 +696,7 @@ ex_rx_intr(struct ex_softc *sc)
MT_DATA);
if (m-m_next == NULL) {
m_freem(ipkt);
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
goto rx_another;
}
m = m-m_next;
diff --git sys/dev/pci/if_age.c sys/dev/pci/if_age.c
index f5f6de5..53903c1 100644
--- sys/dev/pci/if_age.c
+++ sys/dev/pci/if_age.c
@@ -1329,7 +1329,7 @@ age_rxeof(struct age_softc *sc, struct rx_rdesc *rxrd)
desc = rxd-rx_desc;
/* Add a new receive buffer to the ring. */
if (age_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse Rx buffers. */
if (sc-age_cdata.age_rxhead != NULL) {
m_freem(sc-age_cdata.age_rxhead);
diff --git sys/dev/pci/if_alc.c sys/dev/pci/if_alc.c
index eac4148..ef22bb5 100644
--- sys/dev/pci/if_alc.c
+++ sys/dev/pci/if_alc.c
@@ -1952,7 +1952,7 @@ alc_rxeof(struct alc_softc *sc, struct rx_rdesc *rrd)
mp = rxd-rx_m;
/* Add a new receive buffer to the ring. */
if (alc_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse Rx buffers. */
if (sc-alc_cdata.alc_rxhead != NULL)
m_freem(sc-alc_cdata.alc_rxhead);
diff --git sys/dev/pci/if_ale.c sys/dev/pci/if_ale.c
index 1e5004e..ef6348f 100644
--- sys/dev/pci/if_ale.c
+++ sys/dev/pci/if_ale.c
@@ -1552,7 +1552,7 @@ ale_rxeof(struct ale_softc *sc)
m = m_devget((char *)(rs + 1), length - ETHER_CRC_LEN,
ETHER_ALIGN, ifp, NULL);
if (m == NULL) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
ale_rx_update_page(sc, rx_page, length, prod);
continue;
}
diff --git sys/dev/pci/if_jme.c sys/dev/pci/if_jme.c
index 25c954f..37a1efa 100644
--- sys/dev/pci/if_jme.c
+++ sys/dev/pci/if_jme.c
@@ -1602,7 +1602,7 @@ jme_rxpkt(struct jme_softc *sc)
/* Add a new receive buffer to the ring. */
if (jme_newbuf(sc, rxd) != 0) {
- ifp-if_iqdrops++;
+ ifp-if_ierrors++;
/* Reuse buffer. */
jme_discard_rxbufs(sc, cons, nsegs - count);
if (sc-jme_cdata.jme_rxhead != NULL) {
diff --git sys/dev/pci/if_se.c sys/dev/pci/if_se.c
index
tiny fstat(1) output formatting nit
makes cloned devices line up well with the rest of the output: _dhcpdhclient 30880 text / 14 -r-xr-xr-x r 283856 _dhcpdhclient 30880 wd /var77953 drwxr-xr-x r 512 _dhcpdhclient 30880 root /var77953 drwxr-xr-x r 512 _dhcpdhclient 308800 /1102 crw-rw-rw- rw null _dhcpdhclient 308801 /1102 crw-rw-rw- rw null _dhcpdhclient 308802 /1102 crw-rw-rw- rw null _dhcpdhclient 308804* route raw 0 0xfe817f34 _dhcpdhclient 308805 pipe 0xfe817f33d080 state: _dhcpdhclient 308806 /var51994 -- w 583 _dhcpdhclient 308807 clone 546 crw--- rw bpf _dhcpdhclient 308808* internet raw ip 0xfe817f1f4000 ok? diff --git usr.bin/fstat/fstat.c usr.bin/fstat/fstat.c index 6efe370..ba17c3d 100644 --- usr.bin/fstat/fstat.c +++ usr.bin/fstat/fstat.c @@ -410,7 +410,7 @@ vtrans(struct kinfo_file2 *kf) else if (!(kf-v_flag VCLONE)) (void)printf( %-8s, kf-f_mntonname); else - (void)printf( clone); + (void)printf( clone ); if (nflg) (void)snprintf(mode, sizeof(mode), %o, kf-va_mode); else
Re: change if_iqdrops to if_ierrors
On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. -- :wq Claudio
Re: change if_iqdrops to if_ierrors
On 29 November 2012 20:49, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. do you mean IFQ_ENQUEUE(ifp-if_snd) drops? they're exported via sysctl_ifq and it seems like netstat has the printing code commented out.
Re: change if_iqdrops to if_ierrors
On Thu, Nov 29, 2012 at 09:10:58PM +0100, Mike Belopuhov wrote: On 29 November 2012 20:49, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. do you mean IFQ_ENQUEUE(ifp-if_snd) drops? they're exported via sysctl_ifq and it seems like netstat has the printing code commented out. Yes. In that case we should make them visible. -- :wq Claudio
Re: change if_iqdrops to if_ierrors
Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly.
Re: change if_iqdrops to if_ierrors
On Thu, Nov 29, 2012 at 09:21:49PM +0100, Mark Kettenis wrote: Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly. True, it would also help in mclgeti drivers to distinguish between packets that got dropped because of errors or because of mclgeti. -- :wq Claudio
Re: change if_iqdrops to if_ierrors
On 29 November 2012 21:21, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly. indeed, freebsd originated drivers (age, ale, alc, jme, se, vte) and ex do this when allocation fails, but vic, xe when something is wrong with the packet. i'd argue that we certainly want to change vic and xe since it has little to do with any input queue whatsoever. but on the other hand adding code to netstat to handle a handful of rather unpopular nics seems to be an overkill. and spreading the if_iqdrops love across the tree doesn't sound like a great use of time.
Re: change if_iqdrops to if_ierrors
On 29 November 2012 21:37, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Thu, Nov 29, 2012 at 09:21:49PM +0100, Mark Kettenis wrote: Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly. True, it would also help in mclgeti drivers to distinguish between packets that got dropped because of errors or because of mclgeti. but we don't increment ierrors when mclgeti fails.
Re: change if_iqdrops to if_ierrors
On Thu, Nov 29, 2012 at 09:37:53PM +0100, Mike Belopuhov wrote: On 29 November 2012 21:21, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly. indeed, freebsd originated drivers (age, ale, alc, jme, se, vte) and ex do this when allocation fails, but vic, xe when something is wrong with the packet. i'd argue that we certainly want to change vic and xe since it has little to do with any input queue whatsoever. but on the other hand adding code to netstat to handle a handful of rather unpopular nics seems to be an overkill. and spreading the if_iqdrops love across the tree doesn't sound like a great use of time. The idea being to fix the other Ethernet drivers after netstat has been fixed to display this counter. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: change if_iqdrops to if_ierrors
From: Mike Belopuhov m...@belopuhov.com Date: Thu, 29 Nov 2012 21:41:28 +0100 On 29 November 2012 21:37, Claudio Jeker cje...@diehard.n-r-g.com wrote: On Thu, Nov 29, 2012 at 09:21:49PM +0100, Mark Kettenis wrote: Date: Thu, 29 Nov 2012 20:49:00 +0100 From: Claudio Jeker cje...@diehard.n-r-g.com On Thu, Nov 29, 2012 at 11:50:09AM -0500, Kenneth R Westerback wrote: On Thu, Nov 29, 2012 at 04:41:09PM +0100, Mike Belopuhov wrote: hi, drivers ex age alc ale jme se vic vte xe upl and octeon/cmac make use of the if_iqdrops counter that is not shown by any of our tools (like netstat). looks like most of its usage comes from freebsd where they show it in the netstat -di output in a new column. do we want to do that or just convert them to if_ierrors since 90% of our drivers do only if_ierrors. there's also doesn't seem to be any rule when to use if_iqdrops (well, since in most drivers there's no input queueing -- check out upl(4) :) the diff below changes all the drivers in our tree to use if_ierrors instead of if_iqdrops. i've decided to leave octeon/cmac driver as is because if_iqdrops is used for debugging purposes there. ack? nack? meh? Seems like a good idea to me to not lose those errors. I have no great desire for a new column in netstat, but no great antagonism to one either. I guess the idea is to show which interfaces are overloading the input queues. At least that is my interpretation of if_iqdrops (input queue drops). In a away it makes sense but I'm not to attached to it. I would prefer we would actually print out the output queue drops on the interface queue. Actually, in the network (hardware) drivers this is used to flag the oh shit, I cannot allocate a new mbuf, let's drop the packet I just received such that I can keep my ring filled conditions. It is somewhat useful to be able to distinguish this condition from packets that were dropped by the hardware because they were not received correctly. True, it would also help in mclgeti drivers to distinguish between packets that got dropped because of errors or because of mclgeti. Not really. but we don't increment ierrors when mclgeti fails. Some don't, some do. I believe that doing so would be wrong. But since we won't refill the ring, the hardware will start dropping packets. Most hardware will set some sort of error bit in this case, and the driver will probably increase if_ierrors in response. Perhaps drivers that can distinguish between packets being dropped because there is no space on the rx ring and packets being dropped because they are corrupt should increase if_iqdrop in the first case and if_ierrors in the second. But I think it makes sense to only use if_iqdrop for packets that we actively drop in the network stack.
Re: cloneable tun
Date: Thu, 29 Nov 2012 13:33:47 +0100
From: Reyk Floeter r...@openbsd.org
btw., I like C and it is still my favorite language (sorry, CS
people). But it shouldn't be a problem to do simple ioctls with most
other languages except shell scripts.
#!/usr/bin/perl
require sys/ioctl.ph;
$TUNSIFUNIT = _IOC(IOC_INOUT, ord('t'), 90, 4);
open(TUN0, +/dev/tun0) or die open;
ioctl(TUN0, $TUNSIFUNIT, $unit = pack(i, -1)) or die ioctl $!;
print Returned: tun.unpack(i, $unit).\n;
close(TUN0);
But you'll need to be a pretty hardcore Perl programmer to be able do this.
My favourite quick-and-dirty language is Python, and I consider
myself a fairly proficient Python programmer. I've never, ever, done
ioctls from Python, and while it looks indeed as if it is possible to
do so, I'm sure it'd take me some effort to get it right.
Re: cloneable tun
My favourite quick-and-dirty language is Python, and I consider myself a fairly proficient Python programmer. I've never, ever, done ioctls from Python, and while it looks indeed as if it is possible to do so, I'm sure it'd take me some effort to get it right. I definitely agree with your statement! I've found ioctls much easier to perform in brainf*ck than in python. Grumpy
Re: cloneable tun
Date: Thu, 29 Nov 2012 00:12:39 +0100 From: Reyk Floeter r...@openbsd.org On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: But currently /dev/tunN is usable from any programming language that that can do reads and writes. With Reyk's changes you need to do an ioctl even for basic usage, which is at best quirky in languages other than C/C++. That feels like a step backward to me. OK, I didn't think about VPN services written in node.js... I'm just kidding, but can you give me any examples of programs using tun that are written in an arbitrary language other than C/C++? There was some machine emulator software that I came across that had some Perl scripts that used /dev/tunN to hook itself up to the network stack. I guess the point I'm trying to make is that it is very simple to use /dev/tunN to insert ethernet packets into the network stack. The requirement to issue an ioctl to be able to use it makes it significantly more complex to do so.
Re: alt signal stack fixes
On Fri, Nov 16, 2012 at 11:45 AM, Philip Guenther guent...@gmail.com wrote: The diff below changes the alt sig stack logic to dynamically determine whether the thread is currently on the alt stack, by comparing the stack pointer against the altstack base and size, so that you get the correct answer if you longjmp out of the signal handler, as tested by regress/sys/kern/stackjmp/ ... Ping? Hello, anyone? I've gotten no test reports on this, not even didn't break anything reports. No one cares about sigaltstack()? Philip Guenther
Re: cloneable tun
Penned by Reyk Floeter on 20121129 6:33.47, we have:
| On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov m...@belopuhov.com wrote:
| But currently /dev/tunN is usable from any programming language that
| that can do reads and writes. With Reyk's changes you need to do an
| ioctl even for basic usage, which is at best quirky in languages other
| than C/C++. That feels like a step backward to me.
|
| sure, we can totally leave tun for legacy use in the shell scripts.
| so i guess reyk should go ahead and implement a dynamic tun interface
| (dun?) with whatever semantics we need and want.
|
| Or even better duh? ;-) I wrote this diff because I wanted to
| experiment with clonable device nodes, I still don't like the fact
| that you have to MAKEDEV a device per dynamic interface, and because
| it adds some extra flexibility. But it doesn't have to go anywhere, I
| didn't even waste much time with writing it yesterday in the
| afternoon.
|
| btw., I like C and it is still my favorite language (sorry, CS
| people). But it shouldn't be a problem to do simple ioctls with most
| other languages except shell scripts.
|
| #!/usr/bin/perl
| require sys/ioctl.ph;
| $TUNSIFUNIT = _IOC(IOC_INOUT, ord('t'), 90, 4);
| open(TUN0, +/dev/tun0) or die open;
| ioctl(TUN0, $TUNSIFUNIT, $unit = pack(i, -1)) or die ioctl $!;
| print Returned: tun.unpack(i, $unit).\n;
| close(TUN0);
|
| reyk
Wouldn't it just be easier to auto assign on first read/write if the
$TUNSIFUNIT ioctl has not yet been called?
Thanks,
--
Todd Fries .. t...@fries.net
|\ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC\ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX)
| PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net
| ..in support of free software solutions. \ sip:4052279...@ekiga.net
\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
