From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 03:36:20 +0200
> If you are serious with the shrinking of the sk_buff, I can send you
> the final patch along with my pending patches for 2.6.13.
Please do. The pkt_type change would get queued for 2.6.14,
and please only send real
Hi David,
> > I found the problem. The hci_usb is using the cb[] by itself and so
> > overwriting the pkt_type value. The attached patch works for me with the
> > hci_usb driver. However I haven't converted all other drivers and
> > checked them. This won't happen until I am back home, because I d
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 02:26:34 +0200
> I found the problem. The hci_usb is using the cb[] by itself and so
> overwriting the pkt_type value. The attached patch works for me with the
> hci_usb driver. However I haven't converted all other drivers and
> che
David S. Miller wrote:
> This probably has nothing to do with why the patch doesn't
> work for you, but the transformation of "incoming" to a "u8"
> from an "int" is not fully correct, because hci_sock.c
> does this:
>
> put_cmsg(msg, SOL_HCI, HCI_CMSG_DIR, sizeof(int),
> &bt_cb(skb)->incom
Hi Dave,
> > The pkt_type zero is not a valid one. We only use 1-4 and 0xff. So this
> > can't be the problem. I assume that the cb is not copied from the driver
> > into the core at some point.
>
> All clones and copies of SKBs copy of the ->cb[] for you.
> So perhaps something is spamming the -
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 01:49:51 +0200
> The pkt_type zero is not a valid one. We only use 1-4 and 0xff. So this
> can't be the problem. I assume that the cb is not copied from the driver
> into the core at some point.
All clones and copies of SKBs copy of
Hi Dave,
> > unfortunatly it is not that straight forward as I thought. The attached
> > patch which modifies the Bluetooth core and the hci_usb driver is not
> > working on my machine.
>
> This probably has nothing to do with why the patch doesn't
> work for you, but the transformation of "incom
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 23:42:11 +0200
> unfortunatly it is not that straight forward as I thought. The attached
> patch which modifies the Bluetooth core and the hci_usb driver is not
> working on my machine.
This probably has nothing to do with why the p
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 23:42:11 +0200
> unfortunatly it is not that straight forward as I thought. The attached
> patch which modifies the Bluetooth core and the hci_usb driver is not
> working on my machine.
Hmmm... I'll see if I can spot anything obviou
Hi Dave,
> > However after a look trough the Bluetooth core it should be quite
> > easy too move the pkt_type into the control buffer. We already use
> > it for a direction bit. The nasty thing is that I have to modify all
> > the drivers. So when you finally decided to shrink the pkt_type, I
> >
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 20:20:35 +0200
> However after a look trough the Bluetooth core it should be quite
> easy too move the pkt_type into the control buffer. We already use
> it for a direction bit. The nasty thing is that I have to modify all
> the driv
Hi Harald,
> I just ran into Marcel Holtmann earlier today. He thinks moving that
> data into the cb is fine, though he has to double-check that.
>
> He also said that he really only needs 5 bits, so even if the current
> pkt_type overloading would persist, we could probably shrink it to make
>
Wensong Zhang wrote:
Well, I hope IPVS people will take care of this. I don't really know
that code too well...
This bit is only to indicate that the sk_buff is already mangled by
IPVS/NAT, so that when both iptables/NAT and IPVS/NAT are enabled,
iptables/NAT will not mangle sk_buff again. I
From: Harald Welte <[EMAIL PROTECTED]>
Date: Wed, 20 Jul 2005 09:23:05 -0400
> On Mon, Jul 18, 2005 at 08:31:45PM -0700, David S. Miller wrote:
> > From: Harald Welte <[EMAIL PROTECTED]>
> > Date: Mon, 18 Jul 2005 00:04:51 +0200
> >
> > > The only real in-tree user of nfcache was IPVS, who only n
Hi,
Sorry for the delay.
On Wed, 20 Jul 2005, Harald Welte wrote:
On Mon, Jul 18, 2005 at 08:31:45PM -0700, David S. Miller wrote:
From: Harald Welte <[EMAIL PROTECTED]>
Date: Mon, 18 Jul 2005 00:04:51 +0200
The only real in-tree user of nfcache was IPVS, who only needs a single
bit. Unfo
On Mon, Jul 18, 2005 at 08:31:45PM -0700, David S. Miller wrote:
> From: Harald Welte <[EMAIL PROTECTED]>
> Date: Mon, 18 Jul 2005 00:04:51 +0200
>
> > The only real in-tree user of nfcache was IPVS, who only needs a single
> > bit. Unfortunately I couldn't find some other free bit in sk_buff to
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Tue, 19 Jul 2005 09:18:38 +0200 (MEST)
> >but for now I'll eat that one-bit member.
>
> What is more important? Being as small as possible using bitfields, or being
> as fast as possible? (Usage of bitfields is some CPU overhead for their
> extract
>but for now I'll eat that one-bit member.
What is more important? Being as small as possible using bitfields, or being
as fast as possible? (Usage of bitfields is some CPU overhead for their
extraction)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
From: Harald Welte <[EMAIL PROTECTED]>
Date: Mon, 18 Jul 2005 00:04:51 +0200
> The only real in-tree user of nfcache was IPVS, who only needs a single
> bit. Unfortunately I couldn't find some other free bit in sk_buff to
> stuff that bit into, so I introduced a separate field for them. Maybe
>
19 matches
Mail list logo
