On Tuesday, April 02, 2013 2:33:18 pm Vijay Singh wrote:
> Hi, this is based on the the understanding that the SS_NBIO is a
> socket state, and not a state of the socket buffer.
Committed, thanks!
--
John Baldwin
___
freebsd-net@freebsd.org mailing lis
Hi, this is based on the the understanding that the SS_NBIO is a
socket state, and not a state of the socket buffer.
F9@[/u/vijay/bsd/CODE/cur/sys/ofed/drivers/infiniband/ulp/sdp]# svn diff
Index: sdp_main.c
===
--- sdp_main.c (revis
On Sun, 25 Nov 2012, Vijay Singh wrote:
Really trivial change.
Yeah, my comment is probably telling; I was wondering about the
history of the code and why it ended up like that but probably haven't
looked it up but added the XXX-BZ. I shall handle this.
/u/vijay/bsd/CODE/cur# svn diff sys/
Really trivial change.
/u/vijay/bsd/CODE/cur# svn diff sys/netinet6/in6_src.c
Index: sys/netinet6/in6_src.c
===
--- sys/netinet6/in6_src.c (revision 243309)
+++ sys/netinet6/in6_src.c (working copy)
@@ -597,11 +597,6 @@
On Mon, 29 Mar 2010, M. Warner Losh wrote:
OK. I'd like to propose the following patch for ipfilter:
Index: sys/contrib/ipfilter/netinet/ip_compat.h
===
--- sys/contrib/ipfilter/netinet/ip_compat.h(revision 205838)
+++ sys/con
OK. I'd like to propose the following patch for ipfilter:
Index: sys/contrib/ipfilter/netinet/ip_compat.h
===
--- sys/contrib/ipfilter/netinet/ip_compat.h(revision 205838)
+++ sys/contrib/ipfilter/netinet/ip_compat.h(working
On Fri, 29 Aug 2008, Sam Leffler wrote:
The bridge code does a deep copy of the packet for each interface it
broadcasts on due the firewall code modifying the headers. It sounds like
this should just be a copy+pullup instead.
I'd not do that. I think there are paths that assume the deep cop
Andrew Thompson wrote:
On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote:
On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
Luigi Rizzo wrote:
...
and to be more explicit - the result of m_pullup is that
the number of bytes specified as m_pullup argume
On Fri, Aug 29, 2008 at 06:41:45PM +0200, Luigi Rizzo wrote:
> On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
> > Luigi Rizzo wrote:
> ...
> > >and to be more explicit - the result of m_pullup is that
> > >the number of bytes specified as m_pullup argument are in
> > >a private piece
At Fri, 29 Aug 2008 18:28:53 +0200,
Luigi Rizzo wrote:
>
> and to be more explicit - the result of m_pullup is that
> the number of bytes specified as m_pullup argument are in
> a private piece of memory -- the 'data' region within the mbuf -- so
> you can freely play with them without trouble.
>
On Fri, Aug 29, 2008 at 09:32:10AM -0700, Sam Leffler wrote:
> Luigi Rizzo wrote:
...
> >and to be more explicit - the result of m_pullup is that
> >the number of bytes specified as m_pullup argument are in
> >a private piece of memory -- the 'data' region within the mbuf -- so
> >you can freely pl
Luigi Rizzo wrote:
On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote:
[EMAIL PROTECTED] wrote:
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
J
On Tue, Aug 26, 2008 at 05:56:13PM -0700, Sam Leffler wrote:
> [EMAIL PROTECTED] wrote:
> >At Tue, 26 Aug 2008 14:50:33 + (UTC),
> >Bjoern A. Zeeb wrote:
> >
> >>On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >>Hi,
> >>
> >>
> >>>At Mon, 25 Aug 2008 21:40:38 +0200,
> >>>John Ha
At Tue, 26 Aug 2008 17:56:13 -0700,
Sam Leffler wrote:
>
> [EMAIL PROTECTED] wrote:
> > At Tue, 26 Aug 2008 14:50:33 + (UTC),
> > Bjoern A. Zeeb wrote:
> >
> >> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
> >>
> >> Hi,
> >>
> >>
> >>> At Mon, 25 Aug 2008 21:40:38 +0200,
> >>> Jo
[EMAIL PROTECTED] wrote:
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I have tried it and it does fix my problem. RIP2 over multicast works
again. :-)
At Tue, 26 Aug 2008 14:50:33 + (UTC),
Bjoern A. Zeeb wrote:
>
> On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
>
> Hi,
>
> > At Mon, 25 Aug 2008 21:40:38 +0200,
> > John Hay wrote:
> >>
> >> I have tried it and it does fix my problem. RIP2 over multicast works
> >> again. :-)
> >
> > Goo
On Tue, 26 Aug 2008, George V. Neville-Neil wrote:
Hi,
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
I have tried it and it does fix my problem. RIP2 over multicast works
again. :-)
Good to hear. I'm waiting on a bit more feedback but I think I'll be
checking this in soon, with a big
At Mon, 25 Aug 2008 21:40:38 +0200,
John Hay wrote:
>
> I have tried it and it does fix my problem. RIP2 over multicast works
> again. :-)
Good to hear. I'm waiting on a bit more feedback but I think I'll be
checking this in soon, with a big comment talking about the
performance implications etc
Greetings,
[EMAIL PROTECTED] wrote:
At Fri, 22 Aug 2008 21:42:00 +0200,
Luigi Rizzo wrote:
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue?
On Mon, Aug 25, 2008 at 09:02:07PM +0200, John Hay wrote:
> On Fri, Aug 22, 2008 at 03:03:30PM -0700, [EMAIL PROTECTED] wrote:
> > At Fri, 22 Aug 2008 22:43:39 +0100,
> > Bruce M. Simpson wrote:
> > >
> > > [EMAIL PROTECTED] wrote:
> > > > Somehow the data that the device needs to do the proper ch
On Fri, Aug 22, 2008 at 03:03:30PM -0700, [EMAIL PROTECTED] wrote:
> At Fri, 22 Aug 2008 22:43:39 +0100,
> Bruce M. Simpson wrote:
> >
> > [EMAIL PROTECTED] wrote:
> > > Somehow the data that the device needs to do the proper checksum
> > > offload is getting trashed here. Now, since it's clear w
At Fri, 22 Aug 2008 22:43:39 +0100,
Bruce M. Simpson wrote:
>
> [EMAIL PROTECTED] wrote:
> > Somehow the data that the device needs to do the proper checksum
> > offload is getting trashed here. Now, since it's clear we need a
> > writable packet structure so that we don't trash the original, I'm
[EMAIL PROTECTED] wrote:
Somehow the data that the device needs to do the proper checksum
offload is getting trashed here. Now, since it's clear we need a
writable packet structure so that we don't trash the original, I'm
wondering if the m_pullup() will be sufficient.
If it's serious enoug
At Fri, 22 Aug 2008 19:43:03 +0100,
Bruce M. Simpson wrote:
>
> We end up calling if_simloop() from a few "interesting" places, in
> particular the kernel PIM packet handler.
>
> In this particular case we're going to take a full mbuf chain copy every
> time we send a packet which needs to be l
At Fri, 22 Aug 2008 21:42:00 +0200,
Luigi Rizzo wrote:
>
> On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
> > [EMAIL PROTECTED] wrote:
> > >I gather you mean that a fast link on which also we're looping back
> > >the packet will be an issue? Since this packet is only going into
On Fri, Aug 22, 2008 at 07:43:03PM +0100, Bruce M. Simpson wrote:
> [EMAIL PROTECTED] wrote:
> >I gather you mean that a fast link on which also we're looping back
> >the packet will be an issue? Since this packet is only going into the
> >simloop() routine.
> >
>
> We end up calling if_simloop
[EMAIL PROTECTED] wrote:
I gather you mean that a fast link on which also we're looping back
the packet will be an issue? Since this packet is only going into the
simloop() routine.
We end up calling if_simloop() from a few "interesting" places, in
particular the kernel PIM packet handler.
At Fri, 22 Aug 2008 03:27:11 +0100,
Bruce M. Simpson wrote:
>
> [EMAIL PROTECTED] wrote:
> >> The only thing i can think of is that it's the UDP checksum,
> >> residing beyond hlen, which is overwritten somewhere in the
> >> call to if_simloop -- in which case perhaps a better fix is
> >> to m_pul
Luigi Rizzo wrote:
On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote:
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix
On Fri, Aug 22, 2008 at 03:27:11AM +0100, Bruce M. Simpson wrote:
> [EMAIL PROTECTED] wrote:
> >>The only thing i can think of is that it's the UDP checksum,
> >>residing beyond hlen, which is overwritten somewhere in the
> >>call to if_simloop -- in which case perhaps a better fix is
> >>to m_pull
[EMAIL PROTECTED] wrote:
The only thing i can think of is that it's the UDP checksum,
residing beyond hlen, which is overwritten somewhere in the
call to if_simloop -- in which case perhaps a better fix is
to m_pullup() the udp header as well ?
It is the checksum that gets trashed, yes.
..
At Thu, 21 Aug 2008 22:35:19 +0200,
Luigi Rizzo wrote:
>
> On Thu, Aug 21, 2008 at 03:11:56PM -0400, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > Turns out there is a bug in the code that loops back multicast
> > packets. If the underlying device driver supports checksum offloading
> > then the pack
On Thu, Aug 21, 2008 at 03:11:56PM -0400, [EMAIL PROTECTED] wrote:
> Hi,
>
> Turns out there is a bug in the code that loops back multicast
> packets. If the underlying device driver supports checksum offloading
> then the packet that is looped back, when it is transmitted on the
> wire, is incor
Hi,
Turns out there is a bug in the code that loops back multicast
packets. If the underlying device driver supports checksum offloading
then the packet that is looped back, when it is transmitted on the
wire, is incorrect, due to the fact that the packet is not fully
copied.
Here is a patch. C
On Thursday 08 May 2008 06:30:50 pm Andre Oppermann wrote:
> John Baldwin wrote:
> > At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are
> > spamming the heck out of our dmesg so I am #if 0'ing all of them out and
> > while doing so ran into this case. Specifically, it does
John Baldwin wrote:
At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are
spamming the heck out of our dmesg so I am #if 0'ing all of them out and
while doing so ran into this case. Specifically, it doesn't actually bump
sysctl net.inet.tcp.log_debug=0 is simpler than #if
On Thu, 8 May 2008, John Baldwin wrote:
At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are
spamming the heck out of our dmesg so I am #if 0'ing all of them out and
while doing so ran into this case. Specifically, it doesn't actually bump
the stat counter unless it succeed
At work all the log(LOG_DEBUG, ...) statements in the TCP code in 7.x are
spamming the heck out of our dmesg so I am #if 0'ing all of them out and
while doing so ran into this case. Specifically, it doesn't actually bump
the stat counter unless it succeeds in allocating memory to log the debug
38 matches
Mail list logo
