d. It was listed as “MFC after 3 days” back in October 2013.
>> >>
>> >> Is this patch missing for a reason?
>> >
>> > I'm wondering too if there's any good reason not to MFC?
>>
>> I also don't see any obvious reason.
>>
&g
On Monday, July 07, 2014 12:58:53 pm hiren panchasara wrote:
> + freebsd-net@,
>
> On Mon, Jul 7, 2014 at 4:37 AM, Harald Schmalzbauer
> wrote:
> > Bezüglich Jan Mikkelsen's Nachricht vom 24.06.2014 04:49 (localtime):
> >> Hi,
> >>
> >> I’m bringing 9.3-RC1 into our local Perforce depot and movin
+ freebsd-net@,
On Mon, Jul 7, 2014 at 4:37 AM, Harald Schmalzbauer
wrote:
> Bezüglich Jan Mikkelsen's Nachricht vom 24.06.2014 04:49 (localtime):
>> Hi,
>>
>> I’m bringing 9.3-RC1 into our local Perforce depot and moving our local
>> patches to 9.2 forward.
>>
>> I noticed that r256920 (changin
(Apologies because of my poor english, it's not my first language.
Corrections are welcome. It's also my first post to this mailing-list)
I'm having some issues running a KVM-virtualized FreeBSD 9-STABLE
(somewhat 4 weeks old, so it has the latest netgraph code). I'm also
running a 7.4-RELEASE (al
Oh: The other interesting bit is that Chrome defaulted to telling the server to
use IW32 if it had no cached value...
I think Google are still heavily tweaking the mechanisms.
Lars
On Aug 14, 2013, at 16:46, "Eggert, Lars" wrote:
> Hi,
>
> On Aug 14, 2013, at 10:36, Lawrence Stewart wrote:
Hi,
On Aug 14, 2013, at 10:36, Lawrence Stewart wrote:
> I don't think this change should have been MFCed, at least not in its
> current form.
FYI, Google's own data as presented in the HTTPBIS working group of the recent
Berlin IETF shows that 10 is too high for ~25% of their web connections:
ts
current form. Enabling the switch to IW=10 on a stable branch is
inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl
branch is poorly named as per the important discussion we had back in
February [1]. I would really prefer we didn't get stuck having to keep
it around by making a stable
On 09.11.2012 17:51, Adrian Chadd wrote:
On 9 November 2012 00:08, Andre Oppermann wrote:
Firewalling doesn't change the packet and no checksum is needed.
NAT does change the packet and the pesky pseudo-header in the TCP/
UDP checksum. However here only the pseudo-header checksum is
recalcula
On 9 November 2012 00:08, Andre Oppermann wrote:
> Firewalling doesn't change the packet and no checksum is needed.
> NAT does change the packet and the pesky pseudo-header in the TCP/
> UDP checksum. However here only the pseudo-header checksum is
> recalculated and reintegrated into the one-co
On 09.11.2012 01:19, Adrian Chadd wrote:
On 8 November 2012 15:55, Andre Oppermann wrote:
At the risk of repeating myself: when a routed packet is fragmented
the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed
or anything else. It remains as originally calculated by the sen
On 8 November 2012 15:55, Andre Oppermann wrote:
> At the risk of repeating myself: when a routed packet is fragmented
> the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed
> or anything else. It remains as originally calculated by the sender
> unchanged in the first fragment
On 09.11.2012 00:32, Adrian Chadd wrote:
On 8 November 2012 06:34, Andre Oppermann wrote:
TCP/UDP doesn't (want to) generate any fragments at all and tries
to avoid it at almost all cost. We want to send very large packets
and have the NIC fragment/segment it (TSO/UDP frag offload).
What ab
On 8 November 2012 06:34, Andre Oppermann wrote:
> TCP/UDP doesn't (want to) generate any fragments at all and tries
> to avoid it at almost all cost. We want to send very large packets
> and have the NIC fragment/segment it (TSO/UDP frag offload).
What about if it's a router and the frames don
On 08.11.2012 05:53, Adrian Chadd wrote:
On 7 November 2012 18:38, YongHyeon PYUN wrote:
On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
If so, may I suggest we perhaps accelerate discussing if_transmit() of
multiple frames per call?
Hmm, actually I'm still not a fan of if_tran
On 08.11.2012 03:38, YongHyeon PYUN wrote:
On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
If so, may I suggest we perhaps accelerate discussing if_transmit() of
multiple frames per call?
Hmm, actually I'm still not a fan of if_transmit() at this moment.
Honestly I don't have goo
e simplify checksum offloading setup.
Modified:
stable/9/sys/dev/ti/if_ti.c
Directory Properties:
stable/9/sys/ (props changed)
stable/9/sys/dev/ (props changed)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
On 7 November 2012 18:38, YongHyeon PYUN wrote:
> On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
>> So I am curious - did this give a real benefit?
>
> In 3.x/4.x days it surely have had helped a lot, I guess mainly
> because the CPU was not fast enough to saturate the link with
> s
ere passed to
> > driver. But there are chances that other packets slip into the
> > interface queue in SMP world. If this happens firmware running on
> > MIPS 4000 processor in the controller would see mixed packets and
> > it shall send out corrupted packet
ut corrupted packets.
> While I'm here simplify checksum offloading setup.
>
> Modified:
> stable/9/sys/dev/ti/if_ti.c
> Directory Properties:
> stable/9/sys/ (props changed)
> stable/9/
On Fri, Sep 07, 2012 at 12:35:53AM -0700, Sean Bruno wrote:
S> Just noted this happened today, running stable/9 ish from august 10th.
S> It looks like I got a good and valid crashdump off of this if anyone is
S> interested.
...
S> --- trap 0xc, rip = 0x80731312, rsp = 0x
Since I saw other panics on our stable/9 I started poking around and found this
one lying around too.
And, I have a crashdump here as well. Not sure about reproduction, but I see
it happened on two seperate servers
over the course of the day. Here is one of them.
igb0: port 0xe880-0xe89f
Just noted this happened today, running stable/9 ish from august 10th.
It looks like I got a good and valid crashdump off of this if anyone is
interested.
igb0: port
0xe880-0xe89f mem
0xfbe6-0xfbe7,0xfbe4-0xfbe5,0xfbeb8000-0xfbebbfff irq 32
at device 0.0 on pci5
igb0: Using MSIX
Hey,
after some back and forth and quite a few people asking me for it and having
asked re@ I have merged the IPv6 offload changes to stable/9 today rather than
after 9.1 as I had planned.
I did not merge driver changes and I am expecting that one or two might
follow-up,
as will SCTP be
On 26. May 2012, at 14:01 , Bjoern A. Zeeb wrote:
Hey.
> WARNING - please refrain from testing IPv6 or updating your HEAD if you do
> not have any of the above two NICs and rely on IPv6, or if you have updated
> and
> are experiencing problems. Disabling -txcsum -tso for the moment should be an
ions and I'd love people to test with as many drivers as
> possible, as I plan to merge it for the upcoming 9.1-RELEASE cycle and
> wouldn't want to ship broken IPv6 in a few months;-)
>
> Here's the patch that should just apply to stable/9 matching what I put into
> HEAD
On May 25, 2012, at 11:55 AM, Bjoern A. Zeeb wrote:
> Hey,
> ... PS: we now also disallow LRO automatically if forwarding is turned on,
> just
> in case you wonder; a change that should have been done years ago;-)
Thank you!!! It was a bit of a surprise (and a little time to diagnose) to find
l
checksum calculations and I'd love people to test with as many drivers as
possible, as I plan to merge it for the upcoming 9.1-RELEASE cycle and
wouldn't want to ship broken IPv6 in a few months;-)
Here's the patch that should just apply to stable/9 matching what I put into
HEAD
> > What am I missing here?
> >
>
> Did you try to use ipfw instead of RADIX_MPATH?
>
> Try something like this:
>
> route add default $router -interface $if1
> ipfw add $number fwd $router ip from $ip2 to any out via $if2
>
I think I've configued lagg(4) into doing what I really want, which
On 5/15/12 10:07 PM, Sean Bruno wrote:
Trying to use two interfaces connected to the same network with the same
default router. The two interfaces have two different IPs on the
same /28 and point at the same default router of .1. I have
successfully configured the machine such that data is comi
and try to come up with a patch.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of David DeSimone [f...@verio.net]
Sent: Tuesday, May 15, 2012 4:14 PM
To: freebsd-net@freebsd.org
Subject: Re: [stable-9]
Li, Qing
On Tue, 2012-05-15 at 16:14 -0700, David DeSimone wrote:
> suggests that there is only ONE default route, pointing to ONE
> interface, igb0. Without an extra default route that is also pointing
> to igb1, I can't see how the system woudl ever forward traffic out
> igb1,
> unless it was directed to
On Tue, 2012-05-15 at 12:55 -0700, Sean Bruno wrote:
>
> On Tue, 2012-05-15 at 12:02 -0700, Li, Qing wrote:
> > The route selection is based on a hash function of source-ip and
> > destination-ip when
> > RADIX_MPATH is enabled. You do not need to perform specific actions, other
> > than perhap
Li, Qing wrote:
>
> The route selection is based on a hash function of source-ip and
> destination-ip when RADIX_MPATH is enabled. You do not need to perform
> specific actions, other than perhaps setting varying weights on each
> entry as an option. So depends on the traffic destination the chose
On Tue, 2012-05-15 at 12:02 -0700, Li, Qing wrote:
> The route selection is based on a hash function of source-ip and
> destination-ip when
> RADIX_MPATH is enabled. You do not need to perform specific actions, other
> than perhaps
> setting varying weights on each entry as an option. So depen
the same one.
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Sean Bruno [sean...@yahoo-inc.com]
Sent: Tuesday, May 15, 2012 11:07 AM
To: freebsd-net@freebsd.org
Subject: [stable-9]
Trying to use two interfaces
Trying to use two interfaces connected to the same network with the same
default router. The two interfaces have two different IPs on the
same /28 and point at the same default router of .1. I have
successfully configured the machine such that data is coming *in* on
both interfaces, but the outpu
36 matches
Mail list logo
