Julian Elischer | 5 May 08:27 2016
Picon

Re: Best option to process packet ACL

On 29/04/2016 5:21 AM, Ze Claudio Pastore wrote:
> 2016-04-28 14:46 GMT-03:00 Jim Thompson <jim <at> netgate.com>:
>
>> If your application is already using DPDK then:
>>
>> 1) it’s not “mostly bypassing the kernel”, it *is* bypassing the kernel.
>>
>> 2) ACLs are already a thing in DPDK:
>> http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html
>>
>> 200Kpps is not a lot of load for even ‘pf’ on slow hardware.
>>
>>> On Apr 28, 2016, at 12:35 PM, Alan Somers <asomers <at> freebsd.org> wrote:
>>>
>>> Even if your application is not a traditional firewall, using pf or ipfw
>>> would save much development time compared to writing your own packet
>>> filter.  They can be configured to do things like redirect packets to
>>> different ports.  You can use that to offload packet filtering from your
>>> application to the firewall, and open multiple sockets in your
>> application
>>> to receive prefiltered packets.
>>>
>>> Of course, pf/ipfw can't be used in combination with DPDK, as you
>>> discovered.  Doesn't DPDK provide access to each queue of a multiqueue
>>> NIC?  If so, you can create multiple filtering threads, and associate
>> each
>>> thread to a single queue of your NIC.
>>>
>>> Good luck, you've got a lot of work ahead of you.
> ok, again, it's not a L3/L4 ACL, I am looking into L3/L4 information but on
(Continue reading)

Dieter BSD | 4 May 00:41 2016
Picon

TCP problems

I have suddenly started seeing TCP problems on a machine "G":
running FreeBSD 10.1
Gigabyte UD5 amd64
2 Ethernet controllers, re0 and ue0:

re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port
0xb000-0xb0ff mem 0xfe600000-0xfe600fff,0xd0000000-0xd0003fff irq 16
at device 0.0 on pci6
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: Chip rev. 0x4c000000
re0: MAC rev. 0x00000000
rgephy0: <RTL8251 1000BASE-T media interface> PHY 1 on miibus0

ue0 is Siig USB-to-Ethernet  Chipset: AX88179

Problem 1: bind(2) fails
Problem 2: copying large files via Ethernet results in data corruption

1) Bind:

C program containing:

  bzero(&server, sizeof(struct sockaddr_in));
  server.sin_family=AF_INET;
  server.sin_port=htons((unsigned short)port_number);
  (void) memcpy((char*)&server.sin_addr, (char*)host->h_addr,
sizeof(server.sin_addr));

  return_code = socket(PF_INET, SOCK_STREAM, 0);
(Continue reading)

Eric McCorkle | 3 May 00:25 2016
Picon
Gravatar

Problem with objcopy corrupting section names

Hello everyone, 

I've been doing quite a bit of work in the efi boot1 and loader codebases.  In particular, I've been trying to
get both boot1 and loader using the same backend filesystem drivers. 

As background, both the boot1 and loader build processes use objcopy to convert the elf format executable
produced by the platform build tools to the PE+ format used by EFI.

I've run into a weird problem where the section names are seemingly being corrupted for boot1. The process
to reproduce this should be simple: just build boot1 and then do objdump -x boot1.efi and you should see
that the section names are corrupted.

The code can be found here.  https://github.com/emc2/freebsd/tree/efize

Before I report this, can someone please do a sanity check and make sure the problem is reproducible and has
doesn't have an easy solution that I've overlooked? 

Thanks, 
Eric
--

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Rozhuk Ivan | 1 May 22:51 2016
Picon

some clang AVX instricts looks broken

Hi!

I try port some SSE code to AVX and found that clang instricts _mm256_extract* broken:

_mm256_extract_epi8(__aymm0, 0) - BAD result
_mm256_extract_epi8(__aymm0, 0) & 0xff - OK
_mm_extract_epi8(_mm256_extractf128_si256(__aymm0, 0), 0) - OK

Same time: _mm256_extract_epi8(__aymm0, 0) build with GCC - OK.

CLANG:
static __inline int __attribute__((__always_inline__, __nodebug__))
_mm256_extract_epi8(__m256i __a, int const __imm)
{
  __v32qi __b = (__v32qi)__a;
  return __b[__imm & 31];
}

GCC:
extern __inline int __attribute__((__gnu_inline__, __always_inline__, __artificial__)) 
_mm256_extract_epi8 (__m256i const __X, int const __N) 
{ 
  __m128i __Y = _mm256_extractf128_si256 (__X, __N >> 4); 
  return _mm_extract_epi8 (__Y, __N % 16); 
}

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
(Continue reading)

trafdev | 1 May 18:46 2016
Picon

corrupted stack (backtrace) from sigaction handler

Hello!

Could you launch attached code on your machine and respond with an 
output (and FreeBSD version).

Here is mine (FreeBSD 10.2) output:

	stack dump [0]  0x40d4e5 <_Z9stackdumpPKc+0x85> at 
/ara/devel/sandbox/new/cpp/Release/cpp
	stack dump [1]  0x40dafd <_Z13signalHandleriP9__siginfoPv+0x3d> at 
/ara/devel/sandbox/new/cpp/Release/cpp
	stack dump [2]  0x801f30997 <pthread_sigmask+0x497> at /lib/libthr.so.3
	stack dump [3]  0x801f301a8 <pthread_getspecific+0xdd8> at /lib/libthr.so.3

All info before signalHandler (foo/foo2 functions) is missed.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Yuri | 27 Apr 23:19 2016

Brief and intermittent system freezes

I changed the motherboard on the 10.3 desktop system and now I am 
getting the "sticky mouse" effect: mouse briefly freezes every few 
seconds. I think USB mouse events aren't propagated to the Xorg process 
in a timely fashion. This also possibly makes the system impaired in 
some other ways too. One thing I can think of is that the network driver 
changed from re(4) to msk(4).

What is the best way to troubleshoot such problem? Anybody experiences 
something similar?

Thanks,
Yuri

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Zé Claudio Pastore | 27 Apr 21:21 2016
Picon

Best option to process packet ACL

Hello everyone,

I would like to hear your suggestion regarding the best approach to process
IP packets for filtering, in such a way I can avoid lowering my pps rate.

Today a have a simple application proxies http application. It's dual
threaded on a 4 core system with low CPU power. The current application
uses two threads, one for control and one for data flow processing.

I need to implement a simple set of stateless filtering, I will process
only:

- src-ip
- dst-ip
- src-port
- dst-port
- iplen
- proto (tcp/udp/other)

My current rate of requests per second is high, around 200K. I have no idea
how I can leverage the IDLE CPUs the best way to implement this ACL
filtering trying not to impact on the pps rate I have today.

I have implemented it serial today (not threaded) and I get 40% performance
loss. I will handle max 128 filter rules, this is a decision which is made.
This is going to be first match wins.

My current plans are to test:

1) Create 6 threads, one to test each aspect of the ACL (src-ip, dst-ip,
(Continue reading)

Devin Teske | 26 Apr 23:51 2016
Picon
Gravatar

Phabricator Badges

Once upon a time (circa July 2015) we had badges in Phabricator. E.g.,

https://reviews.freebsd.org/badges/recipients/4/ <https://reviews.freebsd.org/badges/recipients/4/>

However, they seem to be gone.
Was there any particular reason why?

I was recently going to use us as an example to show why Phab may be better than what we use at $work (ReviewBoard).
--

-- 
Devin
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Rafael Rodrigues Nakano | 26 Apr 22:38 2016
Picon

Contributing to FreeBSD

Hello,

I would like to contribute to FreeBSD in terms of code, but I don't know
where, exactly. I use most of the time C in my free time hobby projects,
but I know a bit of C++ and the concept of OOP. But I found no way to
contribute to the system itself, I should study more before entering the
Operating System Programming world. However, like I said, I'd like to
contribute to FreeBSD, so, should I try to enhance the user-level
applications or something like this? (I saw that 'freebsd-version' is a
shell script and I think I could make a more information-detailed version
in C, or something else). Sorry if it's a really dumb question, I like
FreeBSD so much and I know I need to contribute to the development somehow.

Is this the correct way (if not, the easiest one) to start contributing to
such a great OS project like this?

And, finally, how exactly I submit my code? CVS? Git? By email?

Thanks in advance.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Sebastian Huber | 26 Apr 14:49 2016
Picon

UMA alloc with max items < potential items in per processor buckets

Hello,

I don't use FreeBSD directly, but instead a port of the FreeBSD network 
stack to RTEMS. So, this problem may not apply to FreeBSD. I observed 
the following problem during an UDP socket create. They are allocated 
from the following zone:

void
udp_init(void)
{

     in_pcbinfo_init(&V_udbinfo, "udp", &V_udb, UDBHASHSIZE, UDBHASHSIZE,
         "udp_inpcb", udp_inpcb_init, NULL, UMA_ZONE_NOFREE,
         IPI_HASHFIELDS_2TUPLE);
     V_udpcb_zone = uma_zcreate("udpcb", sizeof(struct udpcb),
         NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
     uma_zone_set_max(V_udpcb_zone, maxsockets);
     EVENTHANDLER_REGISTER(maxsockets_change, udp_zone_change, NULL,
         EVENTHANDLER_PRI_ANY);
}

In my setup maxsockets is 32. This is probably artificially small 
compared to a real FreeBSD machine. The system has 24 processors, so we 
need 128 * 24 items for the per processor cache buckets. This is 
considerably lager than the single keg of the zone can deliver. Thus in 
case a processor without a per processor bucket tries to do a 
uma_zalloc(V_udpcb_zone, M_NOWAIT | M_ZERO), then it will get no item if 
other processors already consumed all items for their per processor 
cache buckets. I adjusted the uma_zone_set_max() like this

(Continue reading)

rank1seeker | 23 Apr 19:12 2016
Picon

py-* ports falsely appearing as deps

Like plaque, in many installed ports after issuing: # make missing
--
devel/py-pytest-capturelog
devel/py-pytest-timeout
devel/py-pytest-xdist
devel/py-virtualenv
devel/py-scripttest
devel/py-pretend
devel/py-freezegun
devel/py-dateutil
--

I can confirm that for; x11-drivers/xf86-video-ati, x11-servers/xorg-server, x11-toolkits/gtk20, ...
Those will also list as deps for ports, even they aren't port's deps and aren't built.

D.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"


Gmane