Hi,
Use IP_RECVIF option.
For IP_SENDIF look at
http://lists.freebsd.org/pipermail/freebsd-net/2007-March/013510.html
I used the patch on my embedded FreeBSD 9.0 boxes and it works fine. I
modificated it slightly to match 9.0.
Svata
On Thu, Apr 19, 2012 at 7:41 AM, Attila Nagy wrote:
>
> Hi,
* Jack Vogel wrote:
> ok then i guess i will upgrade to 8.3-R, is the driver there reasonably
> new?
>
> Yes, that should be fine.
Jack thanks, btw. i can quite reliably reproduce this issue.
So if you or anybody else is interested in some data i might
be able to get it.
--lars
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code and the kernel do return in
various points of the path. Here are some results which
I hope you find interesting.
Test conditions:
- intel i7-870 CPU
On Wednesday, April 18, 2012 7:40:17 pm Sean Bruno wrote:
>
> On Wed, 2012-04-18 at 09:49 -0700, Sean Bruno wrote:
> > ok, good. that at least confirms that I correctly translated between
> > the driver code and documented specification.
> >
> > I will try 8k as a test for now and see how that
OH, well that's interesting to know, thanks John.
Jack
On Thu, Apr 19, 2012 at 5:22 AM, John Baldwin wrote:
> On Wednesday, April 18, 2012 7:40:17 pm Sean Bruno wrote:
> >
> > On Wed, 2012-04-18 at 09:49 -0700, Sean Bruno wrote:
> > > ok, good. that at least confirms that I correctly translat
On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote:
> I have been running some performance tests on UDP sockets,
> using the netsend program in tools/tools/netrate/netsend
> and instrumenting the source code and the kernel do return in
> various points of the path. Here are some results w
On Thu, 2012-04-19 at 07:09 -0700, Jack Vogel wrote:
> OH, well that's interesting to know, thanks John.
>
> Jack
>
Front end box looks pretty happy today at 8k descriptors.
http://people.freebsd.org/~sbruno/igb_8k_stats.txt
Under peak, we're approaching 20MBytes/sec in and out of the
interfa
On Thu, Apr 19, 2012 at 12:26 PM, Sean Bruno wrote:
> On Thu, 2012-04-19 at 07:09 -0700, Jack Vogel wrote:
> > OH, well that's interesting to know, thanks John.
> >
> > Jack
> >
>
>
> Front end box looks pretty happy today at 8k descriptors.
>
> http://people.freebsd.org/~sbruno/igb_8k_stats.txt
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code and the kernel do return in
various points of the path. Here are some results which
I hope you find interes
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
> On 19.04.2012 15:30, Luigi Rizzo wrote:
> >I have been running some performance tests on UDP sockets,
> >using the netsend program in tools/tools/netrate/netsend
> >and instrumenting the source code and the kernel do return in
> >va
>> This is indeed a big problem. I'm working (rough edges remain) on
>> changing the routing table locking to an rmlock (read-mostly) which
>
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the
I noted a small nit in the comments of sys/dev/e1000/if_igb.h
Index: if_igb.h
===
--- if_igb.h(revision 234466)
+++ if_igb.h(working copy)
@@ -52,7 +52,7 @@
#define IGB_MAX_TXD4096
/*
- * IGB_RXD: Maximum numbe
On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
> >> This is indeed a big problem. ?I'm working (rough edges remain) on
> >> changing the routing table locking to an rmlock (read-mostly) which
> >
>
> This only helps if your flows aren't hitting the same rtentry.
> Otherwise you still con
On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> This is indeed a big problem. ?I'm working (rough edges remain) on
>> >> changing the routing table locking to an rmlock (read-mostly) which
>> >
>>
>> This only helps if your flow
On 19.04.2012 22:34, K. Macy wrote:
This is indeed a big problem. I'm working (rough edges remain) on
changing the routing table locking to an rmlock (read-mostly) which
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itse
>> This only helps if your flows aren't hitting the same rtentry.
>> Otherwise you still convoy on the lock for the rtentry itself to
>> increment and decrement the rtentry's reference count.
>
>
> The rtentry lock isn't obtained anymore. While the rmlock read
> lock is held on the rtable the rele
On 19.04.2012 22:46, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote:
On 19.04.2012 15:30, Luigi Rizzo wrote:
I have been running some performance tests on UDP sockets,
using the netsend program in tools/tools/netrate/netsend
and instrumenting the source code
On 19.04.2012 23:17, K. Macy wrote:
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.
The rtentry lock isn't obtained anymore. While the rmlock read
lock is hel
>
> Yes, but the lookup requires a lock? Or is every entry replicated
> to every CPU? So a number of concurrent CPU's sending to the same
> UDP destination would content on that lock?
No. In the default case it's per CPU, thus no serialization is
required. But yes, if your transmitting thread ma
On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann wrote:
> On 19.04.2012 23:17, K. Macy wrote:
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the rtentry's reference count.
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
> On 19.04.2012 22:46, Luigi Rizzo wrote:
...
> >What might be moderately expensive are the critical_enter()/critical_exit()
> >calls around individual allocations.
>
> Can't get away from those as a thread must not migrate away
> wh
On 20.04.2012 00:03, Luigi Rizzo wrote:
On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
On 19.04.2012 22:46, Luigi Rizzo wrote:
The allocation happens while the code has already an exclusive
lock on so->snd_buf so a pool of fresh buffers could be attached
there.
Ah, there it
On Fri, Apr 20, 2012 at 12:37:21AM +0200, Andre Oppermann wrote:
> On 20.04.2012 00:03, Luigi Rizzo wrote:
> >On Thu, Apr 19, 2012 at 11:20:00PM +0200, Andre Oppermann wrote:
> >>On 19.04.2012 22:46, Luigi Rizzo wrote:
> >>>The allocation happens while the code has already an exclusive
> >>>lock on
Howdy,
At the moment the prototype for udp6_input() is the following:
int
udp6_input(struct mbuf **mp, int *offp, int proto)
and udp_input() looks like this:
void
udp_input(struct mbuf *m, int off)
As far as I can tell we immediately change **mp to *m and *offp to off
in udp6_input() and we al
On 20. Apr 2012, at 01:44 , George Neville-Neil wrote:
> Howdy,
>
> At the moment the prototype for udp6_input() is the following:
>
> int
> udp6_input(struct mbuf **mp, int *offp, int proto)
>
> and udp_input() looks like this:
>
> void
> udp_input(struct mbuf *m, int off)
>
> As far as I c
25 matches
Mail list logo
