hi again..
pardon me, but I still have not find anything to solve my problem with
using pam/telnetd..
my problem is:
I need pam.d/telnetd to be always used as telnet aaa configs.. but when a
non-sra telnet connection is created, pam.d/login is used for that telnet
session's aaa configurations..
Hi,
There's a lot of good stuff to review here, thanks!
Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless to keep
locking things like that on a per-packet basis. We should be able to do
this in a cleaner way - we can defer RX into a CPU pinned taskqueue and
convert the interrupt
Mindaugas Rasiukevicius wrote:
Hi,
OK, to summarise what has been discussed:
- Problem
There is a need to perform more complex operations from the BPF program.
Currently, there is no (practical) way to do that from the byte-code.
Such functionality is useful for the packet filters or other com
In article <521f4522.5070...@netbsd.org>,
Darren Reed wrote:
>
>The current implementation of BPF makes it very hard to expand
>the instruction set without impinging on the ability to make
>future changes due to the way in which instructions are codified
>into 32bits. Whilst the method of support
> No problem with fnv_hash().
Doesn't it have bad mixing? Good distribution is important since this code is
for load balancing.
FNV is also slower compared to most of the newer non-cryptographic hashes,
certainly on large keys, but even on small ones. Of course, performance will
vary with the a
On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
> There are a number of other places in the kernel where migration to an rmlock
> makes sense -- however, some care must be taken for four reasons: (1) while
> read locks don't experience line contention, write locking becomes observab
Darren Reed wrote:
> Mindaugas Rasiukevicius wrote:
> > Hi,
> >
> > OK, to summarise what has been discussed:
> >
> > - Problem
> >
> > There is a need to perform more complex operations from the BPF program.
> > Currently, there is no (practical) way to do that from the byte-code.
> > Such functi
Hi,
Adrian Chadd wrote:
> >> > It provides us a capability to offload more complex packet
> >> > processing. My primary user would be NPF in NetBSD, e.g. one of the
> >> > operations is to lookup an IP address in a table/ipset.
> >
> > I would like to coordinate the reservation of BPF opcodes tho
On Aug 29, 2013, at 7:42 AM, John Baldwin wrote:
> On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
>> There are a number of other places in the kernel where migration to an
>> rmlock
>> makes sense -- however, some care must be taken for four reasons: (1) while
>> read locks don
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
>
> On Aug 29, 2013, at 7:42 AM, John Baldwin wrote:
>
> > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
> >> There are a number of other places in the kernel where migration to an
> >> rmlock
> >> makes sense -- howeve
On Thu, Aug 29, 2013 at 1:27 AM, T.C. Gubatayao wrote:
> > No problem with fnv_hash().
>
> Doesn't it have bad mixing? Good distribution is important since this
> code is
> for load balancing.
>
The poor mixing in FNV hash comes from the 8-bit XOR operation. But that
provides fine mixing of the
On Thu, Aug 29, 2013 at 1:42 AM, Alan Somers wrote:
> On Mon, Aug 26, 2013 at 2:40 PM, Andre Oppermann
> wrote:
>
> > On 26.08.2013 19:18, Justin T. Gibbs wrote:
> >
> ...
>
> >> Are there other checksums we should be looking at in addition to FNV?
> >>
> >
> > siphash24() is fast, keyed and str
On 29 August 2013 08:28, Mindaugas Rasiukevicius wrote:
> I have added these to the NetBSD tree:
>
> #define BPF_MISCOP(code) ((code) & 0xf8)
> #defineBPF_TAX 0x00
> +#defineBPF_COP 0x20
> +#defineBPF_COPX0x40
> #define
The example below breaks with "Protocol not available"
But what is wrong? Isn't this the correct usage?
LOCAL_CREDS are only handled in kern/uipc_usrreq.c for AF_LOCAL, so it
isn't clear why this doesn't work.
Yuri
--- example.c ---
#include
#include
#include
#include
#include
main() {
On Aug 29, 2013, at 12:45 PM, Alan Somers wrote:
> I pulled all four hash functions out into userland and microbenchmarked them.
> The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash is
> slower, and siphash24 is the slowest. Also, Clang resulted in much faster
> code than gcc.
I'd like to merge r254341 from user/np/cxl_tuning to head if there are
no objections. It eliminates a couple of iffy looking constructs in
uipc_mbuf.c
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/uipc_mbuf.c?r1=254334&r2=254341&diff_format=u
-
Always increment o
On Thu, Aug 29, 2013 at 1:33 PM, T.C. Gubatayao wrote:
> On Aug 29, 2013, at 12:45 PM, Alan Somers wrote:
>
> > I pulled all four hash functions out into userland and microbenchmarked
> them.
> > The upshot is that hash32 and fnv_hash are the fastest, jenkins_hash is
> > slower, and siphash24 is
On Tue, Aug 27, 2013 at 1:09 AM, Andrey V. Elsukov wrote:
> On 27.08.2013 01:07, Craig Rodrigues wrote:
> > Hi,
> >
> > On box 2, since I this is a debug kernel with WITNESS and INVARIANTS
> > enabled, I get a kernel panic. (see attached core.txt.gz)
>
> It seems the log was stripped by maillist.
On 8/29/13 11:48 AM, Yuri wrote:
The example below breaks with "Protocol not available"
But what is wrong? Isn't this the correct usage?
LOCAL_CREDS are only handled in kern/uipc_usrreq.c for AF_LOCAL, so it
isn't clear why this doesn't work.
Yuri
--- example.c ---
#include
#include
#incl
On 08/29/2013 14:31, Alfred Perlstein wrote:
Looks like SOCK_SEQPACKET doesn't support LOCAL_CREDS because its
protosw doesn't contain the entry for:
.pr_ctloutput = &uipc_ctloutput,
Have a look at src/sys/kern/uipc_usrreq.c at around lines 280-332:
But SOCK_DGRAM produces the
On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
> They're faster, but even with this change, jenkins_hash is still 6 times
> slower than FNV hash.
Actually, I think your test isn't accurately simulating memory access, which
might be skewing the results.
For example, from net/if_lagg.c:
On Aug 29, 2013, at 5:40 PM, T.C. Gubatayao wrote:
> On Aug 29, 2013, at 4:21 PM, Alan Somers wrote:
>
>> They're faster, but even with this change, jenkins_hash is still 6 times
>> slower than FNV hash.
>
> Actually, I think your test isn't accurately simulating memory access, which
> might be s
I'd like to merge r254342 from user/np/cxl_tuning to head if there are
no objections.
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/kern_mbuf.c?r1=254334&r2=254342&diff_format=u
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/sys/mbuf.h?r1=254334&r2=254342&diff_format=u
---
Old Synopsis: BPF_COP/BPF_COPX instruction reservation (sync with NetBSD)
New Synopsis: [bpf] [patch] BPF_COP/BPF_COPX instruction reservation (sync with
NetBSD)
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Aug 30 03:11:33 UT
On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
> > Mindaugas Rasiukevicius wrote:
> > > Hi,
> > >
> > > OK, to summarise what has been discussed:
> > >
> > > - Problem
> > >
> > > There is a need to perform more complex operations from the BPF program.
> > >
25 matches
Mail list logo
