Re: double vlans - once again - experiment unsucsessfull
well, we've tired both "tunings" - the short-one suggested my M.Balikov and the
longer-one, suggested by B.Davis
in both cases - "Protocol not supported"
how we've done this:
on FreeBSD 5.3 stable:
edited if_vlan.c
then
make buildworld
make installworld
mergemaster
make clean
the test:
ifconfig vlan1 create
ifconfig vlan2 create
ifconfig vlan1 vlan 1 vlandev em0
ifconfig vlan2 vlan 2 vlandev vlan1
SIOCSETVLAN: "Protocol not supported"
or maybe it's possible to use hardware and software tagging simultaneously?
we could achieve double tagging proces by combining hardware and software tag
in the ethernet packet.
Re: double vlans - once again.
Brooks Davis
Mon, 20 Dec 2004 10:28:56 -0800
On Sat, Dec 18, 2004 at 08:57:58PM +0200, Mihail Balikov wrote:
> I have done this 2 years ago for FreeBSD 4-STABLE
>
> in sys/net/if_vlan.c in vlan_config(), replace
>
>if (p->if_data.ifi_type != IFT_ETHER)
> return EPROTONOSUPPORT;
>
> with
>
>if (p->if_data.ifi_type != IFT_ETHER &&
>p->if_data.ifi_type != IFT_L2VLAN)
> return EPROTONOSUPPORT;
Hmm, for -current this appears incomplete. I think the following is
what is needed. Any one in a position to test this?
-- Brooks
Index: if_vlan.c
===
RCS file: /home/ncvs/src/sys/net/if_vlan.c,v
retrieving revision 1.73
diff -u -p -r1.73 if_vlan.c
--- if_vlan.c 15 Aug 2004 06:24:42 - 1.73
+++ if_vlan.c 20 Dec 2004 18:25:48 -
@@ -273,7 +273,8 @@ vlan_clone_match_ethertag(struct if_clon
/* Check for . style interface names. */
IFNET_RLOCK();
TAILQ_FOREACH(ifp, &ifnet, if_link) {
- if (ifp->if_type != IFT_ETHER)
+ if (ifp->if_type != IFT_ETHER &&
+ ifp->if_type != IFT_L2VLAN)
continue;
if (strncmp(ifp->if_xname, name, strlen(ifp->if_xname)) != 0)
continue;
@@ -566,6 +567,7 @@ vlan_input(struct ifnet *ifp, struct mbu
} else {
switch (ifp->if_type) {
case IFT_ETHER:
+ case IFT_L2VLAN:
if (m->m_len < sizeof(*evl) &&
(m = m_pullup(m, sizeof(*evl))) == NULL) {
if_printf(ifp, "cannot pullup VLAN header\n");
@@ -641,7 +643,8 @@ vlan_config(struct ifvlan *ifv, struct i
VLAN_LOCK_ASSERT();
- if (p->if_data.ifi_type != IFT_ETHER)
+ if (p->if_data.ifi_type != IFT_ETHER &&
+ p->if_data.ifi_type != IFT_L2VLAN)
return (EPROTONOSUPPORT);
if (ifv->ifv_p)
return (EBUSY);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: %cpu in system - squid performance in FreeBSD 5.3
As a follow up to the below (original message at the very bottom), I installed a load balancer in front of the machines which terminates the tcp connections from clients and opens up a few, persistent connections to each server over which requests are pipelined. In this scenario everything is copasetic: last pid: 3377; load averages: 0.12, 0.09, 0.08 up 0+17:24:53 10:02:13 31 processes: 1 running, 30 sleeping CPU states: 5.1% user, 0.0% nice, 1.8% system, 1.2% interrupt, 92.0% idle Mem: 75M Active, 187M Inact, 168M Wired, 40K Cache, 214M Buf, 1482M Free Swap: 4069M Total, 4069M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 474 squid 960 68276K 62480K select 0 53:38 16.80% 16.80% squid 311 bind 200 10628K 6016K kserel 0 12:28 0.00% 0.00% named It's actually so good that one machine can now handle all traffic (around 180 Mb/s) at < %50 cpu utilization. Seems like something in the network stack is responsible for the high %system cpu util... jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Behl Sent: Tuesday, December 07, 2004 9:17 AM To: Sean Chittenden Cc: [EMAIL PROTECTED] Subject: Re: %cpu in system - squid performance in FreeBSD 5.3 I upgraded to STABLE but most cpu time is still being spent in system. This system is doing ~20Mb/s total with all content being grabbed out of memory. I see similar results when running MySQL (a lot of time being spent in system) Any ideas on what updates to be on the lookout for that might help with this? Am I right in guessing that this is a SMP issue and doesn't have anything to do with AMD architecture? thx FreeBSD www2 5.3-STABLE FreeBSD 5.3-STABLE #2: Sun Dec 5 21:06:14 PST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP amd64 last pid: 15702; load averages: 0.15, 0.31, 0.31up 0+19:55:14 09:09:28 38 processes: 2 running, 36 sleeping CPU states: 5.4% user, 0.0% nice, 12.7% system, 3.4% interrupt, 78.4% idle Mem: 163M Active, 284M Inact, 193M Wired, 72K Cache, 214M Buf, 1245M Free Swap: 4069M Total, 4069M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 486 squid 960 79820K 73996K CPU1 1 110:00 15.04% 15.04% squid 480 squid 960 75804K 70012K select 0 105:56 14.89% 14.89% squid Sean Chittenden wrote: >> but the % system time can fluctuate up to 60 at times. My question >> is if this is about the type of performance I could expect, or if >> people have seen better. > > > I don't know about other people, but I suspect you're running into > lock contention. Try using a post 5.3 snapshot (something from > RELENG_5) since alc@ has set debug.mpsafevm=1, which lets many calls > to the VM run without GIANT, which I suspect is your problem and why > the system usage is all over the place. -sc > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]" howdy, I've got a dual proc AMD64 (2gHz) FreeBSD 5.3R system running two squid processes (to take advantage of both CPUs). Each process is doing around 195 req/s, and the total bandwidth is ~40Mb/s (gig nic via bge driver). Squid is being used exclusively as a reverse proxy, with all content being served out of memory (very little disk activity). Top shows: CPU states: 16.0% user, 0.0% nice, 42.7% system, 7.6% interrupt, 33.6% idle Mem: 898M Active, 569M Inact, 179M Wired, 214M Buf, 171M Free Swap: 4069M Total, 4069M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 14598 squid 108 0 463M 459M select 0 39.2H 59.96% 59.96% squid 14605 squid 105 0 421M 416M CPU0 1 38.4H 49.95% 49.95% squid but the % system time can fluctuate up to 60 at times. My question is if this is about the type of performance I could expect, or if people have seen better. I was expecting to see much better performance, seeing how everything is being served out of memory, but maybe I'm asking too much? 400 reqs/s from RAM doesn't seem like much. Is this a FreeBSD issue (anybody else with similar experience)? A majority of the cpu time being spent in system would seem to indictate such. What is all the system load? How can i tell? Any help/pointers/remarks appreciated thanks, jeff ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quick question about the tired ipf/ipnat/"dmz"/bridge scenario
If memory serves me right, Andrew Heyn wrote: > Quoting http://www.moatware.com/support/docbook/faq-bridge.html, > > 10.8. Why can't hosts on a NATed interface talk to hosts on a bridged > interface? > This frequently happens when someone wants to bridge an interface to their > WAN to use it as a DMZ, and wants to put all of the hosts on their LAN > interface behind a NAT. This is actually a fairly reasonable and natural > thing to want to do. Interesting. This text is part of a document that appears to be, almost verbatim, copied from the documentation from m0n0wall, a FreeBSD-based firewall package. The original is at: http://m0n0.ch/wall/docbook/ I have some thoughts about this, but they're way off-topic for this list. > The problem here is that ipnat and bridging (at least as implemented in > FreeBSD) don't play well together. Packets from the LAN to the DMZ go out > just fine, but in the other direction, it seems like the packets arriving on > the unnumbered bridge interface don't get looked up correctly in the ipnat > state tables. > > I've managed to convince myself that solving this is Really Really Hard > (TM). The irritating thing is that there's no theoretical reason why this > should be difficult...it all comes down to implementation details. > > > Is there any way at all, even with kludges, to get this to work? I'd be > extremely interested if there was any to accomplish this, as specified > above. I wrote this after I implemented m0n0wall's filtered bridging feature and had about a dozen people ask me this question, which is a reasonable question to ask, but tiring after you've heard it more than about five times. :-p My memory is a bit hazy but I think the problem was ipnat doesn't know that packets arriving on the unnumbered bridge interface need to have inbound NAT stuff done to them. It would need to know or figure out that the inbound interface was in a bridging group and that one of the other interfaces in the group was the interface being used for outbound NAT packets. I bet one could probably get this to work, if they were willing to hack up IPFilter and get it to understand the bridge(4) data structures. Bruce. signature.asc Description: This is a digitally signed message part
Re: TCP/IP over USB
--On Thursday, December 23, 2004 13:25:16 +0900 Sangwoo Shim <[EMAIL PROTECTED]> wrote: On Wed, Dec 22, 2004 at 07:15:16PM -0800, Pat Lashley wrote: [snip] Now that that's out of the way, Sangwoo, could you post the details of your dubp + ng_eiface solution? I might want to switch to that. -Pat Ah, I don't have the YOPY anymore. So I can't describe every detail. But the outline was: 1. Add YOPY's device id/vendor id to USB_MATCH() of /sys/dev/usb/udbp.c. (I cannot recall the exact values, but it can be discovered by usbdevs -v or looking at Linux's usbnet driver's header.) Already have it from my tweaks to the if_cdce driver. For those who might be following this thread, here are the values for my YP 3700: Vendor 0x22b8 Product 0x4902 Release 0x0001 Class 0x0002 Subclass0x Protocol0x The Vendor and Product are the only values necessary for the driver; and I suspect that in this case, there's no real advantage to specifying any of the others in usbd.conf. For completeness, I would be interested in obtaining values for the YP 3500 and YP 3000. 2. Recompile udbp.ko and kldload it. (do 'make all install' in /sys/modules/udbp) 3. kldload ng_eiface.ko. 4. Create ng_eiface node and connect it to the data hook of the udbp node. e.g. do 'ngctl mkpeer udbp0: eiface data ether' 5. Set ngethX appropriately. (using ifconfig). This gave me over 400KB/s ftp connection. You could send a PR in udbp also, I suppose? :-) Thanks, I'll give that a try after the holidays. If I wind up going that route instead of cdce, I will submit a PR with the YOPY's values. -Pat ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
