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
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
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
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
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
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
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
_
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
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
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 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 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 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 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 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.
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
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
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
> 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
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/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
-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
>>
>>
-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
>
> 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
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
25 matches
Mail list logo
