ip_flow and ipf_tos
It seems to me that it would be useful to break out the ip_tos field in the ipflow_lookup() function, just like in the ipflow_hash() function, and make it an unsigned long (the packing of the structure makes it a 32 bit value (or 64 bit, on Alpha) anyway. This also means calling the mtod() (which is a macro) before the call to ipflow_create() and adding a u_long parameter there (or u_int32_t, if you prefer). The net upshot of this is that it would be possible to use any unsigned (32 bit, in most cases) value to do the flow identification, so that, other than ipflow_fastforward() itself, the ip_tos is not necessarily used for the flow identification. This is useful for local hash preterbation: the common case for any application other than a generic router is going to have identical ip_tos values on almost all traffic, which makes it not very useful for uniquifying the hash. Rather than dictate what I personally think would be useful, I'd like to have implementation-not-policy; also, the break out of the value would make the code more generally useful. Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only the first 6 bits are used in the hash, while the hash value pass itself is a 32 bit value (in most cases: it's "unsigned"). I'd like to push the value into the same space as the src.s_addr feedback, which would have the net effect of making 2 more bits of the standard implementation useful. What do people think about this? The changes themselves are really trivial, and it only puts an extra push/pop into the common code path in order to get the functionality, and doesn't bloat the data structure size at all... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
[no subject]
unsuscribe freebsd-net
Re: load balancing with 2 nic cards possible?
You may try some other kind of load balance and fail safe from www.xgforce.com. It's a layer 3 and layer 7 global clustering software for FreeBSD. - Original Message - From: "Baldur Gislason" <[EMAIL PROTECTED]> To: "Terry Lambert" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, April 27, 2002 9:14 AM Subject: Re: load balancing with 2 nic cards possible? > I have tried that fec driver, no luck. I get the interface up, but when I try > to transmit packets over it I get "invalid argument" or something like that, > I had the network cards hooked to a Cisco catalyst and I had grouped the > ports, and I've tried two types of network cards, 3com 905C and Intel > EtherExpress 100 > > Baldur Gislason > > On Saturday 27 April 2002 06:07, you wrote: > > Gary Stanley wrote: > > > Is it possible to split the load of IP traffic with 2 ethernet cards on a > > > 4.x machine? I'm new to "load balancing" in a sense, however, I'd like to > > > try something that seems more "robust" > > > > http://people.freebsd.org/~wpaul/FEC/4.x/ > > > > -- Terry > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
soisdisconnected tweak.
When soisdisconnected is called on a socket, the connection is marked as broken the socket can't recieve or send any more data. As far as I can tell, any data which is queued for output cannot be sent, but remains queued in the socket until it is closed. The patch below makes soisdisconnected drop whatever data is queued, so that the mbufs can be reused straight away and you don't have to wait for the socket to be closed. I've been running this patch on several 4.X machines for some time and on my -current box at home with no side effects. I wonder if there is any reason not to commit it? David. Index: sys/kern/uipc_socket2.c === RCS file: /cvs/FreeBSD-CVS/src/sys/kern/uipc_socket2.c,v retrieving revision 1.85 diff -u -r1.85 uipc_socket2.c --- sys/kern/uipc_socket2.c 20 Mar 2002 04:39:32 - 1.85 +++ sys/kern/uipc_socket2.c 24 Mar 2002 09:21:50 - @@ -157,6 +157,7 @@ so->so_state &= ~(SS_ISCONNECTING|SS_ISCONNECTED|SS_ISDISCONNECTING); so->so_state |= (SS_CANTRCVMORE|SS_CANTSENDMORE|SS_ISDISCONNECTED); wakeup((caddr_t)&so->so_timeo); + sbdrop(&so->so_snd, so->so_snd.sb_cc); sowwakeup(so); sorwakeup(so); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: load balancing with 2 nic cards possible?
Matt wrote: > You may try some other kind of load balance and fail safe from > www.xgforce.com. It's a layer 3 and layer 7 global clustering software for > FreeBSD. Wrong kind of "load balancing". The original poster wanted channel bonding, not server load balancing. The layer 3 in the referenced product is (apparently) not really layer 3. VIPs alone do not a layer 3 load balancer make. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: soisdisconnected tweak.
] When soisdisconnected is called on a socket, the connection is ] marked as broken the socket can't recieve or send any more data. ] As far as I can tell, any data which is queued for output cannot ] be sent, but remains queued in the socket until it is closed. ] ] The patch below makes soisdisconnected drop whatever data is queued, ] so that the mbufs can be reused straight away and you don't have ] to wait for the socket to be closed. A shutdown guarantees that the data is transferred from the socket buf to the TCP buf. The real question here is how you get to the state you claim is happening: the so isdisconnected() should stall the calling process until the data has drained, if this is the case, or it should never get called until the buffer is empty. In general, it's valid to have data sitting there waiting, if the data has been sent, but not acknowledged, since an ACK for a previous segment -- indicating that some of the data was lost in transit -- will trigger a retransmit. The retransmitted data has to come from somewhere, for the TCP close semantics to be correct. So back to the real question: how do you get into a situation where data that is *rightly* never to be transmitted is hung there waiting? I can't see how this can ever legitimately happen. Is this maybe part of the sysctl/tcpcb hack thing? If so, then the correct place to do this is on the sysctl write to get rid of the socket: not in the soisdisconnected() call... in other words, it's a discrete event, and has to be handled as such. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
