On 01/28/2012 02:12 AM, Weongyo Jeong wrote:
> Hello Kip,
>
> I had looked flowtable code briefly and still not sure whether I
> understand it correctly. At this moment I have a question.
>
> Is it possible to apply flowtable techniques for forwarding packets? If
> I understand it right it looks
Four very quick points:
- Enabling flowtable can help provided you don't have a large (greater
than a few thousand) number of peers.
- I have a patch under review to cache the rtentry (L3) and llentry
(L2) in the inpcb for TCP connections, which improves scaling at high
packet rates.
- You'll want
On Mon, Jun 13, 2011 at 4:58 PM, Mikolaj Golub wrote:
> Hi,
>
> Automatic receive buffer sizing works only for connections in ESTABLISHED
> state. In tcp_input() auto resizing code is under "if (tp->t_state ==
> TCPS_ESTABLISHED && ...)" branch.
>
> This is unfortunate for HAST, which uses one dir
On Mon, Jul 7, 2008 at 6:07 PM, Mike Tancsa <[EMAIL PROTECTED]> wrote:
> At 02:44 PM 7/7/2008, Paul wrote:
>
>> Also my 82571 NIC supports multiple received queues and multiple transmit
>> queues so why hasn't
>> anyone written the driver to support this? It's not a 10gb card and it
>> still suppo
On Mon, Jul 7, 2008 at 6:22 PM, Paul <[EMAIL PROTECTED]> wrote:
> I read through the IGB driver, and it says 82575/6 only... which is the new
> chip Intel is releasing on the cards this month 2 port
> and october 4 port, but the chips are on some of the motherboards right now.
> Why can't it also
>> I have a pre-production card. With some bug fixes and some tuning of
>> interrupt handling (custom stack - I've been asked to push the changes
>> back in to CVS, I just don't have time right now) an otherwise
>> unoptimized igb can forward 1.04Mpps from one port to another (1.04
>> Mpps in on i
On Tue, Jul 8, 2008 at 1:46 PM, Brian McGinty <[EMAIL PROTECTED]> wrote:
>> I have a pre-production card. With some bug fixes and some tuning of
>> interrupt handling (custom stack - I've been asked to push the changes
>> back in to CVS, I just don't have time right now) an otherwise
>> unoptimized
On Fri, Jul 11, 2008 at 11:44 PM, Brian McGinty <[EMAIL PROTECTED]> wrote:
>> Hi Brian
>> I very much doubt that this is ceteris paribus. This is 384 random IPs
>> -> 384 random IP addresses with a flow lookup for each packet. Also,
>> I've read through igb on Linux - it has a lot of optimizations
On Sat, Jul 19, 2008 at 7:17 PM, Brian McGinty <[EMAIL PROTECTED]> wrote:
> G'day Kip,
>
>> I'm hoping to get to it some time in August. I'm a bit behind in my
>> contracts at the moment.
>
> A few weeks ago, I did a quick comparison of the driver between
> FreeBSD and Linux, and found quite a few
TOE drivers need to be able to directly enqueue data in to a socket
buffer and thus benefit from having knowledge of sockbuf internals.
However, there is no need for them to know about other socket
definitions. Thus I would like to move sockbuf and accompanying
definitions to their own header.
Th
Actually, I'd like to re-factor multiple parts of socketvar in to
separate files.
Please provide feedback on the following:
http://www.fsmware.com/socketvar_refactor.diff
Thanks,
Kip
On Sun, Jul 20, 2008 at 3:14 PM, Kip Macy <[EMAIL PROTECTED]> wrote:
> TOE drivers need
On Mon, Jul 21, 2008 at 10:36 AM, David Christensen
<[EMAIL PROTECTED]> wrote:
> I'm working on implementing multi-queue support for a 10Gb
> device on FreeBSD and I wanted to find out the current state
> of the OS with regards to supporting this. It seems that
> support for multiple receive queue
Thanks for the follow-up.
On Thu, Jul 24, 2008 at 12:54 AM, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Sun, 20 Jul 2008, Kip Macy wrote:
>
>> Actually, I'd like to re-factor multiple parts of socketvar in to separate
>> files.
>>
>> Please p
Hi Robert,
I updated the patch to reflect your requested changes. Please confirm that
your concerns have been addressed.
Thanks,
Kip
On Thu, Jul 24, 2008 at 12:54 AM, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Sun, 20 Jul 2008, Kip Macy wrote:
>
> Actually, I'd lik
See RFC 3168 and 3540. In short it uses some of the options bits to
provide "explicit congestion notification."
-Kip
On Tue, Jul 29, 2008 at 7:02 PM, Wilkinson, Alex
<[EMAIL PROTECTED]> wrote:
>0n Wed, Jul 30, 2008 at 02:04:52AM +0100, Rui Paulo wrote:
>
>>After some chat with other TCP fo
Unless anyone complains I intend to commit the following change to
HEAD. It makes it possible to use an arbitrary number of rx queues up
to the maximum allowed by hardware. The current driver only allows 1,
2, 4, or 8.
http://www.fsmware.com/ixgbe.diff
_
Can you help me out a bit with your workload?
tcp_offload_connect(...) needs to determine which interface an address
corresponds to see if that interface supports TCP offload. The code
does the exact same thing as ip_output does except it doesn't have the
inpcb locked (which isn't used as part of
On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Mike Tancsa wrote:
>>
>> At 10:16 PM 8/23/2008, Kip Macy wrote:
>>>
>>> Can you help me out a bit with your workload?
>>>
>>> tcp_offload_connect(...) needs to de
Yes, he has the same issue.
-Kip
On Sat, Aug 23, 2008 at 10:59 PM, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
>>
>> On Sat, Aug 23, 2008 at 10:52 PM, Julian Elischer <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Mike Tancsa wro
It is simply a knob to adjust on all new server network cards. You
could benefit from it on a predominantly UDP workload. I believe that
tcp_input is still sufficiently serialized that it would not make
sense for TCP workloads.
-Kip
On Fri, Oct 24, 2008 at 2:12 PM, Bartosz Giza <[EMAIL PROTECTED]
As a point of reference for fellow readers:
http://www.google.com/search?hl=en&q=brian.mcginty+freebsd&btnG=Google+Search&aq=f&oq=
On Sun, Nov 2, 2008 at 12:46 AM, Brian McGinty <[EMAIL PROTECTED]> wrote:
> I don't know nothing about mxge so I can't comment, but I know that
> FreeBSD ixgbe driver
Calling arpresolve on an rtentry looked up by rtalloc_mpath_fib won't
work because a gratuitous clone route is created without llinfo
attached. As far as I can tell, routes should only ever be cloned for
initial host route creation during a resolve to store arp information.
Index: sys/net/radix_m
> The reason I am asking is that people are still seeing panics from
> the rnh locking and aren't even able to boot machines.
I have not seen this. Please tell me where this occurs.
> Mixng route
> locking bugs with this rewrite will be painful. As I hope that the
> rnh bugs will be solved within
I think that you're request to not monopolize the AF_INET slot is
reasonable. Do you intend to merge bms_netdev before 8 branches (I'm
guessing this coming summer)?
Cheers,
Kip
On Thu, Dec 11, 2008 at 10:18 AM, Bruce M. Simpson wrote:
> Hi,
>
> Just skimming this I notice it uses the if_afdata[
Native ATM relies on the use of route cloning for managing virtual
circuits. Support for route cloning will be removed from the kernel in
the near future. I thus need to determine how many users of NATM there
are and their availability for testing changes.
Thanks,
Kip
_
On Thu, Dec 11, 2008 at 6:35 PM, Sean Thomas Caron wrote:
> Hi Kip,
>
> I am currently using NATM on FreeBSD/sparc64 with FORE PCA-200E boards. It
> is a little buggy but it works and I am hoping to continue along with it as
> long as I can. :)
Hi Sean,
Thanks for the prompt response. Are you run
The arp-v2 changes have been committed into HEAD.
>> Please report problems to me and Kip Macy.
>
> Not sure if its related or not, but if I create and destroy a lagg port, I
> get a panic
> e.g.
>
>
> 0[current]# ifconfig lagg0 laggproto failover laggport igb0 laggport i
Try changeid 186209.
Thanks,
Kip
On Wed, Dec 17, 2008 at 3:32 AM, Mike Tancsa wrote:
> At 01:34 AM 12/15/2008, Qing Li wrote:
>
>> Hi All,
>>
>> The arp-v2 changes have been committed into HEAD.
>> Please report problems to me and Kip Macy.
>
> Not sure if
adimir Grebenschikov wrote:
>> On Mon, 15 Dec 2008 06:34:13 GMT, Qing Li wrote:
>>
>>>> The arp-v2 changes have been committed into HEAD.
>>>> Please report problems to me and Kip Macy.
>>
>> Wine is not build any more:
>>
>> ...
>> cc
Hi Harti,
Let me first preface this e-mail by saying that you and I have had
very little contact prior to this. The comments below are meant to
explain the point of view of myself and that of a number of other
developers with whom I have spoken, not to criticize you or trivialize
your point of vie
The should be fixed with 186468. Please confirm.
Thanks,
Kip
On Tue, Dec 23, 2008 at 2:01 PM, Antoine Brodin wrote:
> On Mon, Dec 15, 2008 at 7:34 AM, Qing Li wrote:
>> Hi All,
>>
>> The arp-v2 changes have been committed into HEAD.
>> Please report problems to me
> What do you think wrt to adding the (possibly optional) int *error and
> returning the errno rather than a (void *)-1? If you'd be ok, I'd can
> prepare the patch. I'd rather break the API now than in a few months.
I would greatly prefer having a dedicated new function that calls in
to it. Ther
"No buffer space available" is ENOBUFS. This error is returned when
the ifq is full - see IFQ_ENQUEUE in if_var.h. You'll almost certainly
want to set ifq_len to larger than the default for a 10 gigabit
driver. This most likely to be a combination of ifq_len being too
small and inadequate txq overf
Known issue. I haven't been around to fix.
Cheers,
Kip
On Wed, Feb 18, 2009 at 1:50 AM, dikshie wrote:
> Hi,
> does anyone see this panic on -HEAD:
>
> panic: _rw_wlock_hard: recursing but non-recursive rw radix node head
> @ /usr/src/sys/net/route.c:831
>
> kdb_enter() at kdb_enter+0x3a
> panic
Interesting. That might explain a problem that Mike Silbersack is
seeing with the latest em driver on vmware.
I don't know of any NICs that actually choke on such frames.
Nonetheless, it is silly behavior. I'll try to see if we can get this
fixed before 7.2.
Thanks,
Kip
On Wed, Apr 15, 2009 at 8
Please see the handbook for providing debugging information. This is a
very generic panic.
-Kip
2009/4/15 Narek Gharibyan :
> Hello Sir/Mdm
>
>
>
> I would like to know is there any solution to problem show below, because we
> use FreeBSD 7.0 in our network structure and we are meeting face to fa
The reasoning behind moving the delay in to shared code is not very compelling.
-Kip
On Wed, Jun 10, 2009 at 2:17 PM, Kip Macy wrote:
> From "cvs blame":
>
> Add workaround for fxp issue at interface initialization with IPv6.
>
> Some LAN card chip for fxp is
>From "cvs blame":
Add workaround for fxp issue at interface initialization with IPv6.
Some LAN card chip for fxp is known to cause problem at
interface initialization with IPv6 enabled. It happens at
some delicate timing.
And also, just adding some DELAY before IPv6 address
autoconfigu
> cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the
> way they are. If the stack's tso6 works, then this is a bug in
> cxgb.
>
It may not have supported it when the driver was ported - I know it
didn't do v6 RSS.
-Kip
___
freebsd-net
Please print out the mbuf's m_hdr and pkthdr.
-Kip
On 4/15/07, Kris Kennaway <[EMAIL PROTECTED]> wrote:
On Sun, Apr 15, 2007 at 11:30:47PM -0400, Kris Kennaway wrote:
> On an 8-core amd64 running up-to-date CVS sources:
>
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid
On 5/1/07, Mukosi Mukwevho <[EMAIL PROTECTED]> wrote:
Hi Kip,
I managed to get the FreedBSD domU booted under Xen. I am having problem
getting IPFW and DUMMYNET working, does the DomU kernel support DUMMYNET?
The IPFW firewall does not seem to start.
Please help.
Congratulations. Given that no
- Original message -
Summary: Using iperf to measure TCP net speed between...
This is not terribly surprising rx is currently a more expensive
operation than tx on FreeBSD. My testing on 10GigE indicates that
there is ample room for improvement.
-Kip
On 5/21/07, root <[EMAIL PROTECTED]> w
One more thing to remember is to raise the socket size on the linux
sender. I found that I got very poor tx performance on linux running
netperf without making the socket buffers fairy large.
-Kip
On 5/21/07, root <[EMAIL PROTECTED]> wrote:
Summary: Using iperf to measure TCP net speed b
Hi Jack -
I believe I've fixed the sun4v breakage caused by the interrupt filter
changes but it appears that em still isn't working. Does Intel test at
all on big endian hardware? If not, what do you do to avoid breaking
e1000 on Linux?
Thanks.
-Kip
___
Ours did too prior to the recent import :D
On 5/21/07, Brad <[EMAIL PROTECTED]> wrote:
On Mon, 21 May 2007 20:59:15 -0700
"Kip Macy" <[EMAIL PROTECTED]> wrote:
> Hi Jack -
> I believe I've fixed the sun4v breakage caused by the interrupt filter
> change
On 5/21/07, Kip Macy <[EMAIL PROTECTED]> wrote:
Hi Jack -
I believe I've fixed the sun4v breakage caused by the interrupt filter
changes but it appears that em still isn't working. Does Intel test at
all on big endian hardware? If not, what do you do to avoid breaking
e1000 o
On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
On 5/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> Yes, Linux is tested on big endian, however FreeBSD testing
> is limited. I would expect the shared code to be ok but the
> core code is tested on little endian only. Do you have some
> notion of
Sun4v runs a hypervisor as part of its firmware. On freebsd it
requires a different kernel from sparc64. Getting the same kernel to
work on both would require more re-work of sparc64 than I felt like
doing given that USIII isn't supported.
There isn't currently an ISO image being produced. Cross-
It probably needs to drop its softc lock around if_input. The SAM_WIFI
contains many other fixes. I'm hoping it will be integrated into cvs
soon.
-Kip
On 5/27/07, Boris Kochergin <[EMAIL PROTECTED]> wrote:
Hi. I got an "SMC SMCWPCI-GM" card the other day, which is one of these:
May 27 01:16:5
On 5/30/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
Does any driver do this now? And if a driver were to coalesce
packets and send something up the stack that violates mss
will it barf?
mxge has a working implementation, cxgb's is bit-rotted at this
instant. I'm going to add an mbuf flag to bypas
Bruce -
All LRO implementations are currently on the host.
On 5/31/07, Bruce M. Simpson <[EMAIL PROTECTED]> wrote:
Jack Vogel wrote:
> On 5/31/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:
>> 0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
>>
>> > Does any driver do this no
He stated previously that they are not compatible.
On 5/31/07, Christian Brueffer <[EMAIL PROTECTED]> wrote:
On Wed, May 30, 2007 at 05:51:35PM -0700, Jack Vogel wrote:
> I wanted to let everyone know that I will soon have a
> new 10G driver to add to the tree. It is a PCI Express
> MSI/X adapte
- Original message -
And for those that don't know much about SCTP, the ben...
Google knows all.
On 6/5/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:
0n Tue, Jun 05, 2007 at 01:56:10PM -0400, Randall Stewart wrote:
> Weongyo Jeong sent me a nice netstat patch that allows
> netst
On 6/6/07, David Christensen <[EMAIL PROTECTED]> wrote:
> I have a version of code ready to MFC, the big difference with CURRENT
> is that TSO is #ifdef'd off until Andre is able to get that back.
Is something broken with TSO? I just added TSO support to bce on
CURRENT
and was planning on MFC'i
Do I need to define additional flags in my config file?
No, unless sctp_pcb.c was somehow removed from your sys/conf/files you
probably need to 'make cleandepend; make depend'. It builds fine for
me with those options.
-Kip
___
freebsd-net@freebs
Interesting -
Randall - does SCTP depend on ipv6? Or did you mean to have a pipe
between inet and inet6?
netinet/sctp_asconf.c optional inet inet6 sctp
netinet/sctp_auth.c optional inet inet6 sctp
netinet/sctp_bsd_addr.c optional inet inet6 sctp
netinet/sctp_crc32.
I'm looking at extending ifnet to support multiple tx queues. It
appears that this will inevitably interact with ALTQ. I don't know
anyone using ALTQ so I need users to raise their hands to eventually
test prospective changes.
Thanks.
-Kip
___
fr
On 9/6/07, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Ok which clever person did this again?
>
> It just broke our product.
> If it hasn't been removed from 7.0 and 6.x yet it's just about to be...
Talk to Sam. I think we added a flag for LRO, may want something more general.
-Kip
___
On 9/6/07, Sam Leffler <[EMAIL PROTECTED]> wrote:
> No. I've already said (multiple times): nuke the code.
Oops - faulty memory - brain too small.
-Kip
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To
My ethng branch supports multiple rx and tx queues.
-Kip
On 9/22/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> Our newest E1000 nic, the 82575, and the Oplin 10G hardware are capable of
> multiple queues both on the receive and the send side. On the receive end for
> the Oplin driver the queues ac
On 9/23/07, Darren Reed <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
> > My ethng branch supports multiple rx and tx queues.
> >
> > -Kip
> >
>
> What are your plans for how we use/manage/interact with the mutiple
> rx/tx queues?
The rx hardware queu
On 10/1/07, Jamie Ostrowski <[EMAIL PROTECTED]> wrote:
> Thats a good idea, but in this particular arrangement we've
> firewalled off all other smtp connections except for a certain small
> range which comes through Postini. All these connections on the
> machine run through the Postini machines,
I've re-factored tcp_output into a number of smaller routines with the
intent of making it easier to work with. I would like feedback on how
to improve it. I've benchmarked the change on 10GigE with no
measurable performance degradation.
The diff can be found at:
http://www.fsmware.com/freebsd/tcp
Jack, you should know by now that we're not Linux. All we care about
is that you not break the code that we rely on. I'm still slightly
embarrassed when I explain to people that I build if_em as a module
because em0 doesn't come up sometimes due to a race condition on
initialization, so I need to b
On Nov 15, 2007 4:25 PM, Jack Vogel <[EMAIL PROTECTED]> wrote:
> On Nov 15, 2007 4:22 PM, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> >
> > Scott Ullrich wrote:
> > > On 11/15/07, Doug Ambrisko <[EMAIL PROTECTED]> wrote:
> > >> Hmm, I forgot about the 2970 which are AMD based. Can you check the
>
On Nov 16, 2007 7:08 AM, Valentin Nechayev <[EMAIL PROTECTED]> wrote:
> Fri, Nov 16, 2007 at 02:40:01, kmacy wrote about "Re: kern/21998: [socket]
> [patch] ident only for outgoing connections":
>
> > Need to confirm that this issue still applies.
> Yes, nothing is changed (at least for versions
On Nov 17, 2007 2:40 PM, kev c <[EMAIL PROTECTED]> wrote:
> I am trying to install freebsd from an ftp server but
> the dhcp configuration is not working in sysinstall.
> It says, no dhcpoffers received..
>
> The computer is wired to a dlink di624 router acting
> as a dhcp server. The server works
On Nov 18, 2007 7:18 PM, Matthew Luckie <[EMAIL PROTECTED]> wrote:
> BIOCSETF and BIOCSETWF call reset_d which discards any packets
> currently in the hold buffer and resets the packet rx count.
>
> The patch below adds BIOCSETFNR, an ioctl that swaps the BPF filter
> without resetting the hold buf
On Jan 10, 2008 2:50 PM, <[EMAIL PROTECTED]> wrote:
> At Sun, 6 Jan 2008 13:47:24 + (GMT),
> rwatson wrote:
> >
> >
> > There's also the opportunity to think about whether it's possible to
> > harden things in such a ways as to not give up our flexibility to
> > keep maintaining and improving
ay send a TSopt in other segments' rather than
> > 'and MUST send', so we must allow it.
> >
> > Discovered by: Rob Zietlow
> > Tracked down by: Kip Macy
> > PR: bin/118005
> >
> > Revision ChangesPath
> > 1.134
Whatever, just run all future changes by silby.
On Jan 24, 2008 2:58 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
> > Did you talk to the original submitter? Note that FreeBSD's TCP stack
> > is for use in servers and is not intending as a valida
On Feb 2, 2008 8:46 PM, Aaditya Rai <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm using release 6.2. I need to do allocations upto
> 8K which are physically contiguous.
>
> Is m_getjcl the right call for this?
>
> Also, if I use m_getjcl to do 4K allocations, after
> two or three allocations I start
For sun4u FreeBSD only supports up through USII which I doubt comes in
any PCI-e systems. sun4v of course only comes with PCI-e but isn't
really in a production-worthy state right now.
-Kip
On Feb 7, 2008 1:17 PM, Claudio Jeker <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 07, 2008 at 01:05:51PM -0
When you say a "recent kernel/world", I take it you're still running 7.0?
-Kip
On Feb 12, 2008 11:38 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have two MP/Multicore Xeon boxes with CX4 based Chelsio cards in
> them. If I boot 7.0-RC1 the cards can talk to each other. If I build
> a recent
Oops sorry ... What is the output of 'sysctl dev.cxgbc.0'?
-Kip
On Feb 13, 2008 12:51 AM, Kip Macy <[EMAIL PROTECTED]> wrote:
> When you say a "recent kernel/world", I take it you're still running 7.0?
>
> -Kip
>
>
>
>
>
> On Feb 12, 20
Yup. -CURRENT has a very different driver from 7.0. It performs much
better, but I don't want to MFC until it gets more test coverage.
-Kip
On 2/13/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> OK, one more data point.
>
> The issue is somewhere between RC2 and CURRENT. I just put RC
You might want to check out sys/modules/cxgb/tom/Makefile.
-Kip
On Feb 17, 2008 1:24 PM, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008, Robert Watson wrote:
>
> Hi,
>
> [cutting a long mail short and randomly replying;-)]
>
> I came across dev/cxgb/ulp/tom/cxgb_tcp_subr.c vs. ne
Are you running 7.0-RELEASE? What I believe was this issue was a
showstopper for it, so I'm surprised to hear of it now.
-Kip
On Tue, Mar 11, 2008 at 5:56 PM, d.s. al coda <[EMAIL PROTECTED]> wrote:
> Hi,
> We recently upgraded one of our webservers to FreeBSD 7, and we started
> receiving com
On Wed, Mar 12, 2008 at 1:48 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
> > Are you running 7.0-RELEASE? What I believe was this issue was a
> > showstopper for it, so I'm surprised to hear of it now.
>
> No, this is a different issue and
On Sat, Mar 22, 2008 at 2:39 PM, Anton Yuzhaninov <[EMAIL PROTECTED]> wrote:
> When TSO enabled on my re NIC, data transferred via network corrupted.
>
> It easy to reproduce using scp:
>
> citrin:~>scp some_file.tar.bz2 some_host:
>
> ..
> Received disconnect from 10.10.10.100: 2: Corrupted MA
I plan on committing the generic kernel level rdma verb and iwarp
infrastructure from OFED as well as the Chelsio iwarp driver to HEAD
next week. The RDMA infrastructure doesn't require any kernel changes
so I don't foresee any need for a lengthy discussion. For the most
part this does not include
I received the following question in a private e-mail that I think
others might be asking.
> what is RDMA and ipwarp ? google didn't help much here :(
RDMA in general is the ability to directly DMA to and from the memory
of a remote host. In this particular context it is the ability to do
so wit
I would like to MFC TOE and RDMA support in the last week of May /
first week of June. My primary objective is that it be present in 7.1.
The re team has not yet decided when the freeze date for 7.1 will be,
so I may end up asking to do it earlier.
The reason I'm bringing it up roughly 6 weeks in
On Thu, Apr 17, 2008 at 11:32 PM, <[EMAIL PROTECTED]> wrote:
> At Thu, 17 Apr 2008 21:00:04 -0700,
>
> Kip Macy wrote:
> >
> > I would like to MFC TOE and RDMA support in the last week of May /
> > first week of June. My primary objective is that it be present
> I apologize for not yet reviewing all the code. I take that last bit
> to mean the drivers can reach up into sockets given those functions?
> I gather this is due to the work necessary to implement RDMA over TCP?
>
TOE for obvious reasons uses the existing socket infrastructure for
integrati
On Wed, Apr 16, 2008 at 5:47 PM, Kip Macy <[EMAIL PROTECTED]> wrote:
> I plan on committing the generic kernel level rdma verb and iwarp
> infrastructure from OFED as well as the Chelsio iwarp driver to HEAD
> next week. The RDMA infrastructure doesn't require any kernel c
On Sun, May 4, 2008 at 6:32 AM, <[EMAIL PROTECTED]> wrote:
> Hi, all
>
> Can I port 4.4BSD-Lite's TCP/IP protocol stack soure code to my own OS
> kernel which is GPL Licence?
>
> I know that 4.4BSD-Lite is BSD Licenced. Is it legal to port BSD Licenced
> code and change it to GPL licence?
Yes
Paul Saab has seen the same. What hardware are you using?
-Kip
On Mon, Jun 9, 2008 at 3:34 PM, <[EMAIL PROTECTED]> wrote:
>
>
>
> Jun 9 18:23:59 ... kernel: em0: Version - 6.7.3> port 0x2000-0x201f mem 0xd802-0xd803,0xd800
> -0xd801 irq 18 at device 0.0 on pci4
> Jun 9 18:23:
I have a Sun T2000 that I generally run with the em driver from as of
July in order to avoid watchdog timeouts. One trivial scenario that
reproduces the problem with 100% consistency is running the ghc
configure script (a 20kloc shell script) over NFS. As the T2000
doesn't exactly represent "typic
On Wed, 18 Oct 2006, Jack Vogel wrote:
> On 10/18/06, Kip Macy <[EMAIL PROTECTED]> wrote:
> > I have a Sun T2000 that I generally run with the em driver from as of
> > July in order to avoid watchdog timeouts. One trivial scenario that
> > reproduces the problem with
If you create a patch against -CURRENT I can test on sun4v. The timeouts
with em on sun4v are so severe that I have to use the driver from June for
any kind of workload.
-Kip
On 11/3/06, Jack Vogel <[EMAIL PROTECTED]> wrote:
I have been hard at work trying to understand and fix the
remaining i
The "discard frame w/o packet header" message comes from ether_input()
if it gets an mbuf that doesn't have the M_PKTHDR flag set. That
can't happen unless something is very wrong with the system. I'd like
to make it a panic. At least then the machine would reboot instead of
just becoming unre
> Either way it sounds like someone has discovered a DOS in bge.
No, it just about has to be a bug -- either in the mbuf allocator, the
driver, or the NIC hardware. M_PKTHDR is a flag in the mbuf header,
an area that isn't touched by packet data. The driver allocates
all of its receive mbufs wi
Evidently FreeBSD violates the LSO spec by sending down up to socket
buffer sized TSO segments to the network card. Is there a way to set
this other than reducing net.inet.tcp.sendbuf_max to a compliant value
(64k)? And is there a way to for a device to communicate to the stack
the maximum length
On 2/25/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:
Kip Macy wrote:
> Evidently FreeBSD violates the LSO spec by sending down up to socket
> buffer sized TSO segments to the network card. Is there a way to set
> this other than reducing net.inet.tcp.sendbuf_max to a complia
Sam Leffler recently added a new entry in -CURRENT for the part. I
think the change needs to MFC'd. Perhaps someone (Max?) could do that.
-Kip
On 2/25/07, Vincent Howell <[EMAIL PROTECTED]> wrote:
Hello,
I'm trying to get my Broadcom (BCM43XX-based) WNIC working in FreeBSD 6.2 but
am un
LSO is MicroSlop's term for TSO :) As usual, they rename it, and
next they do something non-standard to er 'differentiate' as the
euphemism goes...
Kinda what Sun's lawsuit back in the 90s against their Java
strategy was all about :)
Nevertheless, I don't understand Kip either, when we do TSO th
64K is the max, and I believe that is taking into account the headers.
What size are you seeing that is larger? Even if an mbuf chain comes
down that large, it does NOT form a single packet, it is packetized by
the hardware into MTU size, as I said, on the wire, ie as the receiver
sees it, its ju
On 2/27/07, Vincent Howell <[EMAIL PROTECTED]> wrote:
I'm using MFC'd one for RELENG_6:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/ndis/subr_ntoskrnl.c?rev=1.71.2.6&content-type=text/x-cvsweb-markup&sortby=date
I was getting more "missing feature" errors before trying the patch a
ral has locking bugs on 6.x. I was under the impression that it is
barely used from how quickly I hit them.
-Kip
On 3/3/07, Kimi Ostro <[EMAIL PROTECTED]> wrote:
Hi list,
I have been using a FreeBSD based wifi network for about 5 months now,
reading the handbook made this a breeze.
1 - 100 of 105 matches
Mail list logo
