On Wed, Feb 11, 2015 at 05:49:35PM + I heard the voice of
Matt Churchyard, and lo! it spake thus:
> > On 11 Feb 2015, at 17:38, Warren Block wrote:
> > ifconfig em0 inet 192.168.1.1/24
>
> Yeah I've been using that format in rc.conf for years. Quicker to
> type and looks tidy.
Ditto. Though
>
> I'm interested in doing this a bit as I now have 5 em(4) interfaces on
> my soon to be router box.
>
> I tried modifying the driver to allow num_queues to be raised and I
> compiled with EM_MULTIQUEUE set, and all I got for my trouble was
> kernel panics.
>
> I'm not sure if the code even works
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/10/15 19:09, Adrian Chadd wrote:
> ... you can still use 1 TX/1 RX ring on -HEAD. If we turn on RSS
> in the driver and have it hardware hash things, then the netisr
> input routine will throw it into the right per-CPU queue and it'll
> distri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/10/15 18:49, Sepherosa Ziehau wrote:
> On Sat, Jan 31, 2015 at 5:11 AM, Sean Bruno
> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf
>>
>>
On 11/02/2015 20:29, John Jasen wrote:
I have several servers that have two Intel 10GbE ports on board. They're
technically Dell daughterboards which have two Intel 1GbE and two 10GbE
ports.
However, the second ix interface is not accessible, and does not seem to
be available. From a brief look
I have several servers that have two Intel 10GbE ports on board. They're
technically Dell daughterboards which have two Intel 1GbE and two 10GbE
ports.
However, the second ix interface is not accessible, and does not seem to
be available. From a brief look, it looks like ix0 and both igb
interface
> On 11 Feb 2015, at 17:38, Warren Block wrote:
>
>> On Wed, 11 Feb 2015, Matt Churchyard wrote:
>>
>> Just been helping someone on the forums who appears to have configured their
>> network interface incorrectly. It looks like they've assigned 250.250.250.0
>> as the netmask.
>> I've tried a
On Wed, 11 Feb 2015, Matt Churchyard wrote:
Just been helping someone on the forums who appears to have configured their
network interface incorrectly. It looks like they've assigned 250.250.250.0 as
the netmask.
I've tried assigning this netmask on a 10.1 machine and ifconfig happily
accepts
hselasky updated this revision to Diff 3734.
hselasky added a comment.
Integrate changes after r278469.
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1438?vs=3607&id=3734
REVISION DETAIL
https://reviews.freebsd.org/D1438
AFFECTED FILES
share/man/man9/Makefile
share/man/man9/tim
adrian accepted this revision.
adrian added a reviewer: adrian.
REVISION DETAIL
https://reviews.freebsd.org/D1805
To: davide, kmacy, np, lstewart, rrs, rwatson, julian, adrian
Cc: emaste, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lis
> On Feb 11, 2015, at 4:51 AM, Julian Elischer wrote:
>
>> On 2/11/15 5:55 PM, Matt Churchyard wrote:
>>
>> I appreciate that it might be 'valid' as a binary mask, but I'm struggling
>> to find any documentation anywhere that actually suggests that it's valid as
>> a network configuration.
On 02/11/2015 05:51, Julian Elischer wrote:
> On 2/11/15 5:55 PM, Matt Churchyard wrote:
>
>>
>> Are there actually valid use cases for these types of network?
> yes.
> I've had networks that were the first and last quarter of a /24, and
> the middle two quarters were separate nets.
>
> Sure, it ma
On 2/11/15 5:55 PM, Matt Churchyard wrote:
I appreciate that it might be 'valid' as a binary mask, but I'm struggling to find
any documentation anywhere that actually suggests that it's valid as a network
configuration. The entire modern CIDR notation, and all the routing system &
hardware bu
On Wed, 11-Feb-2015 at 20:10:26 +1100, Ian Smith wrote:
> On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote:
> > On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote:
> > > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote:
> > > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Se
On 2015-2-11, at 09:59, Matt Churchyard wrote:
>> Just been helping someone on the forums who appears to have configured their
>> network interface incorrectly. It looks like they've assigned 250.250.250.0
>> as the netmask.
> that's not invalid. The netmask is a mask and not a prefix like in I
On 2015-2-11, at 09:59, Matt Churchyard wrote:
> Just been helping someone on the forums who appears to have configured their
> network interface incorrectly. It looks like they've assigned 250.250.250.0
> as the netmask.
that's not invalid. The netmask is a mask and not a prefix like in IPv6.
On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote:
> On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote:
> > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote:
> > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote:
> > > > On 10.02.2015 00:21, Andre Albsmeier
Hello,
Just been helping someone on the forums who appears to have configured their
network interface incorrectly. It looks like they've assigned 250.250.250.0 as
the netmask.
I've tried assigning this netmask on a 10.1 machine and ifconfig happily
accepts it.
Is there any reason why FreeBSD a
davide added inline comments.
INLINE COMMENTS
sys/kern/uipc_sockbuf.c:234 Thanks for spotting i'll fix up and upload a new
patch.
REVISION DETAIL
https://reviews.freebsd.org/D1809
To: davide, kmacy, np, rrs, lstewart, rwatson
Cc: julian, freebsd-net
_
davide added a comment.
Robert,
an added (somewhat related) note.
SCTP has already its own sockbuf(s) and this makes integration very hackish in
the tree. IIRC glebius experienced this himself while working on sendfile(),
and I'm pretty sure rrs@ is kind of familiar with the problem. Introducin
rwatson requested changes to this revision.
rwatson added a comment.
This revision now requires changes to proceed.
Looks like some serious transcription errors are in this patch.
INLINE COMMENTS
sys/kern/uipc_sockbuf.c:225 Should this be so->so_rcv?
sys/kern/uipc_sockbuf.c:234 Should this be
rwatson added a comment.
Seems reasonable. I'm slightly surprised that any code other than sbwait()
actually implements the sleep on sb_acc, and wonder if either a use of
abstraction improvement, or an actual abstraction improvement, is needed to fix
t4_ddp.c.
REVISION DETAIL
https://reviews
davide added a comment.
Mainly for consistency at this point with whatever else it's used in the stack.
REVISION DETAIL
https://reviews.freebsd.org/D1809
To: davide, kmacy, np, rrs, lstewart, rwatson
Cc: julian, freebsd-net
___
freebsd-net@freebsd.or
julian added a subscriber: julian.
julian added a comment.
Is the reason here to just make the lines shorter or is there a deeper reason?
(e.g. to prepare for some upcoming change)
REVISION DETAIL
https://reviews.freebsd.org/D1809
To: davide, kmacy, np, rrs, lstewart, rwatson
Cc: julian, free
julian accepted this revision.
julian added a reviewer: julian.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1805
To: davide, kmacy, np, lstewart, rrs, rwatson, julian
Cc: emaste, freebsd-net
___
freebs
25 matches
Mail list logo
