Old Synopsis: sys/dev/netmap memory allocation improvement
New Synopsis: [netmap] [patch] sys/dev/netmap memory allocation improvement
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Aug 9 01:29:19 UTC 2013
Responsible-Changed-Wh
Old Synopsis: sys/dev/netmap patch for Linux compatibility
New Synopsis: [netmap] [patch] sys/dev/netmap patch for Linux compatibility
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Aug 9 01:26:45 UTC 2013
Responsible-Changed-Wh
Yup, it's an incredibly unsafe pattern. It also leads to the pattern where
auxiliary processing is handed off to a taskqueue, which then interleaves
the lock ownership with the ithread and produces out-of-order packet
reception.
Scott
On Aug 8, 2013, at 5:18 PM, Adrian Chadd wrote:
> .. and it
.. and it's not just about "saturate the port" with traffic.
It's also about "what happens if I shut down the MAC whilst I'm in the
process of programming in new RX/TX descriptors?"
The ath(4) driver had a spectacular behaviour where if you mess things
up the wrong way it will quite happily DMA c
On Thu, Aug 8, 2013 at 2:46 PM, Matthew D. Fuller
wrote:
> On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of
> Michael Sierchio, and lo! it spake thus:
>>
>> pkg_add -r ipsc
>
> For another, there's a "cidrcalc" program installed by devel/libcidr
> (full disclosure: of which I'm the au
On Thu, Aug 08, 2013 at 08:55:38AM -0700 I heard the voice of
Michael Sierchio, and lo! it spake thus:
>
> pkg_add -r ipsc
For another, there's a "cidrcalc" program installed by devel/libcidr
(full disclosure: of which I'm the author) that does similar things:
% cidrcalc -bs 10.80.128.35/27
Add
> hello guys,
>
> i have a question about ip addresses. i know my question is not related to
> freebsd but i googled a lot and found nothing useful and don't know where i
> should ask my question.
>
> i want to know how can i calculate the number of ip addresses in a range?
> for example if i have
On Aug 7, 2013, at 10:16 PM, Warner Losh wrote:
>
> On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
>
>> .. and I bet it's not a design pattern, and this is total conjecture on my
>> part:
>>
>> * the original drivers weren't SMP safe;
>> * noone really sat down and figured out how to corre
pkg_add -r ipsc
> ipsc -gch 10.80.128.0/27
Network class:A
Network mask: 255.0.0.0
Network mask (hex): FF00
Network address: 10.80.128.0
Subnet bits: 19
Max subnets: 524288
Full subnet mask: 255.255.255.224
Full subnet ma
On Thu, Aug 8, 2013, at 10:44, Jason Hellenthal wrote:
> Try subcalc, it's in ports.
>
I always kept ipcalc installed, but it looks like there's another called
sipcalc, too. I'll have to check these out myself and see if any have
merits over each other.
___
Try subcalc, it's in ports.
--
Jason Hellenthal
Inbox: jhellent...@dataix.net
Voice: +1 (616) 953-0176
JJH48-ARIN
On Aug 8, 2013, at 7:30, Patrick Lamaiziere wrote:
> Le Thu, 8 Aug 2013 11:34:22 +0430,
> s m a écrit :
>
>> hello guys,
>>
>> i have a question about ip addresses. i know
Darren Reed wrote:
> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> > Darren Reed wrote:
> >>>
> >>> You do not have to use it.
> >>
> >> I get no choice - it is in the kernel by default.
> >>
> >
> > There is no default coprocessor. Here is your choice: do not call
> > bpf_set_cop(9) a
On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>>>
>>> You do not have to use it.
>>
>> I get no choice - it is in the kernel by default.
>>
>
> There is no default coprocessor. Here is your choice: do not call
> bpf_set_cop(9) and those instructions will effectively b
Le Thu, 8 Aug 2013 11:34:22 +0430,
s m a écrit :
> hello guys,
>
> i have a question about ip addresses. i know my question is not
> related to freebsd but i googled a lot and found nothing useful and
> don't know where i should ask my question.
>
> i want to know how can i calculate the number
Darren Reed wrote:
> >
> > You do not have to use it.
>
> I get no choice - it is in the kernel by default.
>
There is no default coprocessor. Here is your choice: do not call
bpf_set_cop(9) and those instructions will effectively be NOPs.
> <...>
>
> No. It's not about calling a function,
Alexander Nasonov wrote:
> Mindaugas Rasiukevicius wrote:
> > Why is it a problem? Given that the byte-code and the functions would
> > come from the same source, some coupling seems natural to me. It is
> > simplistic anyway: some already parsed offsets or values could be
> > passed through the
On Aug 8, 2013, at 1:14 AM, Darren Reed wrote:
> A BPF program generated on Linux is just as valid as on Solaris or NetBSD.
Not necessarily - negative offsets in load and store instructions are supported
on Linux to access some metadata that's not in the packet data, but those
aren't, as far
On Thu, Aug 8, 2013 at 12:04 AM, s m wrote:
> hello guys,
>
> i have a question about ip addresses. i know my question is not related to
> freebsd but i googled a lot and found nothing useful and don't know where i
> should ask my question.
>
> i want to know how can i calculate the number of ip a
On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed wrote:
>>>
>>> I would like propose new BPF instructions for the misc category: BPF_COP
>>> and BPF_COPX. It would provide a capability of calling an external
>>> function - think of BPF "coprocessor".
>>
>> No.
>>
>
> You do not
hello guys,
i have a question about ip addresses. i know my question is not related to
freebsd but i googled a lot and found nothing useful and don't know where i
should ask my question.
i want to know how can i calculate the number of ip addresses in a range?
for example if i have 192.0.0.1 192.
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote:
> .. and I bet it's not a design pattern, and this is total conjecture on my
> part:
>
> * the original drivers weren't SMP safe;
> * noone really sat down and figured out how to correctly synchronise
> all of this stuff;
> * people did the minim
21 matches
Mail list logo