* Re: Fw: kernel 2.6 libipq kernel hang
From: Patrick McHardy @ 2005-06-04 16:40 UTC (permalink / raw)
To: mailinglist.chris; +Cc: Andrew Morton, netdev
In-Reply-To: <20050406155828.1584d7cd.akpm@osdl.org>
Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Wed, 6 Apr 2005 15:12:05 -0400
> From: Mailing List <mailinglist.chris@gmail.com>
> To: linux-kernel@vger.kernel.org
> Subject: kernel 2.6 libipq kernel hang
>
> /sbin/iptables -t mangle -A POSTROUTING -d 192.168.3.0/24 -j QUEUE
> /sbin/iptables -t mangle -A PREROUTING -s 192.168.3.0/24 -j QUEUE
>
> If anyone has any suggestions about what I am doing wrong in either
> the libipq program or the client or server programs, or any ideas
> about what is going on with netlink, please let me know.
Please try latest -git, Harald fixed a bug that could cause a deadlock
when ip_queue was used in PRE_ROUTING.
Regards
Patrick
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Christoph Hellwig @ 2005-06-04 11:58 UTC (permalink / raw)
To: Herbert Xu
Cc: Christoph Hellwig, David S. Miller, James Morris,
Linux Crypto Mailing List, netdev
In-Reply-To: <20050604112606.GA1799@gondor.apana.org.au>
On Sat, Jun 04, 2005 at 09:26:06PM +1000, Herbert Xu wrote:
> On Sat, Jun 04, 2005 at 12:23:14PM +0100, Christoph Hellwig wrote:
> > On Sat, Jun 04, 2005 at 09:46:23AM +1000, Herbert Xu wrote:
> > > struct crypto_frag {
> > > struct page *page;
> > > u16 offset;
> > > u16 length;
> > > };
> >
> > we have this structure as skb_frag_struct and bio_vec already, care
> > to use the same structure with a generic name for all of them?
>
> I certainly would have no problems merging with skb_frag_struct.
> However, merging with bio_vec would mean that either bio_vec would
> have to drop down to 16-bit counters, or crypto_frag would have to
> move up to 32-bit counters.
the usage of 16bit counters in bio_vec doesn't make sense, and if did
all others would have to move to 32bit aswell (in case we started
supporting page sizes that aren't addressable by 16bits)
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 11:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604112314.GA19819@infradead.org>
On Sat, Jun 04, 2005 at 12:23:14PM +0100, Christoph Hellwig wrote:
> On Sat, Jun 04, 2005 at 09:46:23AM +1000, Herbert Xu wrote:
> > struct crypto_frag {
> > struct page *page;
> > u16 offset;
> > u16 length;
> > };
>
> we have this structure as skb_frag_struct and bio_vec already, care
> to use the same structure with a generic name for all of them?
I certainly would have no problems merging with skb_frag_struct.
However, merging with bio_vec would mean that either bio_vec would
have to drop down to 16-bit counters, or crypto_frag would have to
move up to 32-bit counters.
The latter is problematic because I'm trying to shrink the size
enough so that we can squeeze four of these things onto the stack.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Christoph Hellwig @ 2005-06-04 11:23 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050603234623.GA20088@gondor.apana.org.au>
On Sat, Jun 04, 2005 at 09:46:23AM +1000, Herbert Xu wrote:
> struct crypto_frag {
> struct page *page;
> u16 offset;
> u16 length;
> };
we have this structure as skb_frag_struct and bio_vec already, care
to use the same structure with a generic name for all of them?
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Evgeniy Polyakov @ 2005-06-04 10:40 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604103249.GA1378@gondor.apana.org.au>
On Sat, 4 Jun 2005 20:32:49 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Jun 04, 2005 at 02:29:39PM +0400, Evgeniy Polyakov wrote:
> >
> > But without sg we sill save 4*sizeof(dma addr) - is it really a price?
>
> We're also reducing the offset/length to 16 bits from 32 bits so we're
> shaving off half the size.
>
> > For hardware we will need to remap it later...
>
> Well we can't modify the supplied scatterlist structure in the
> crypto API anyway since we don't have exclusive ownership of it.
> Since we can't expect the user of the crypto API to do the mapping
> this space is basically wasted.
So why not remove it completely?
Sycnhronous hardware (like VIA/freescale processors) do not use at all
any scaterlists, so it is not needed there.
CryptoAPI does not use half of the scaterlist structure.
CryptoAPI design can not be used with "interruptible" hardware like
HIFN, so for asynchronous hardware we need some kind of remapping
anyway, so why just not to move to the new fragments Herbert introduced
all over the place in CryptoAPI?
But pleaso do not remove skb_to_sgvec() :)
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 10:32 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604142939.4e2efc55@zanzibar.2ka.mipt.ru>
On Sat, Jun 04, 2005 at 02:29:39PM +0400, Evgeniy Polyakov wrote:
>
> But without sg we sill save 4*sizeof(dma addr) - is it really a price?
We're also reducing the offset/length to 16 bits from 32 bits so we're
shaving off half the size.
> For hardware we will need to remap it later...
Well we can't modify the supplied scatterlist structure in the
crypto API anyway since we don't have exclusive ownership of it.
Since we can't expect the user of the crypto API to do the mapping
this space is basically wasted.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Evgeniy Polyakov @ 2005-06-04 10:29 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604102204.GA1214@gondor.apana.org.au>
On Sat, 4 Jun 2005 20:22:04 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Jun 04, 2005 at 02:17:31PM +0400, Evgeniy Polyakov wrote:
> >
> > Static scaterlists are not used and new are dinamically allocated.
>
> That's precisely why we're having this discussion. We can now
> encrypt/decrypt a 1500 byte packet in 2us so the last thing we
> want is to impose additional latencies on the common case unless
> it's absolutely required.
>
> If we can shrink the structure used between IPsec and the crypto
> layer then we can allocate the sgbuf off the stack for 99% of
> the users.
I do see that 4 sg are enough for 99% of the users, I event think
2 is enough - it will be 8kb, almost the maximum seen 9kb jumbo frame.
But without sg we sill save 4*sizeof(dma addr) - is it really a price?
For hardware we will need to remap it later...
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 10:22 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604141731.37479347@zanzibar.2ka.mipt.ru>
On Sat, Jun 04, 2005 at 02:17:31PM +0400, Evgeniy Polyakov wrote:
>
> Static scaterlists are not used and new are dinamically allocated.
That's precisely why we're having this discussion. We can now
encrypt/decrypt a 1500 byte packet in 2us so the last thing we
want is to impose additional latencies on the common case unless
it's absolutely required.
If we can shrink the structure used between IPsec and the crypto
layer then we can allocate the sgbuf off the stack for 99% of
the users.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Evgeniy Polyakov @ 2005-06-04 10:17 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604095854.GA1003@gondor.apana.org.au>
On Sat, 4 Jun 2005 19:58:54 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Sat, Jun 04, 2005 at 01:55:35PM +0400, Evgeniy Polyakov wrote:
> >
> > processing code. And you can not easily move away of SA lock due to
> > synchronous problems with the same tfm.
>
> This is not true. The tfm context contains no shared state apart
> from the IV. As the IV can be specified through the *_iv functions,
> this allows crypto API users to process the same cipher tfm on two
> CPUs in parallel.
>
> If you don't believe me just wait for my upcoming patches to IPsec.
Sure I believe you, in tfm there are no shared objects except data.
But can we catch the situation when we encrypting the same skb?
As far as I can see skb_cow_data() must take care of it.
You are right, encrypting is safe.
Here is part of esp_output() I use for acrypto.
Static scaterlists are not used and new are dinamically allocated.
@@ -95,7 +239,90 @@
esph->spi = x->id.spi;
esph->seq_no = htonl(++x->replay.oseq);
+
+#ifdef CONFIG_ACRYPTO
+ do {
+ struct crypto_session_initializer ci;
+ struct crypto_data data;
+ struct scatterlist *sg;
+ struct crypto_session *s;
+ u8 *key, *iv;
+
+ nfrags++; /* key */
+
+ if (esp->conf.ivlen)
+ nfrags++;
+ memset(&ci, 0, sizeof(ci));
+ memset(&data, 0, sizeof(data));
+
+ ci.operation = CRYPTO_OP_ENCRYPT;
+ ci.mode = crypto_tfm_get_mode(tfm);
+ ci.type = crypto_tfm_get_type(tfm);
+ ci.priority = 0;
+ ci.callback = &esp4_async_callback;
+
+ if (ci.mode == 0xffff || ci.type == 0xffff)
+ goto sync_crypto;
+
+ sg = kmalloc(sizeof(struct scatterlist)*nfrags, GFP_ATOMIC);
+ if (!sg)
+ goto error;
+ skb_to_sgvec(skb, sg, esph->enc_data+esp->conf.ivlen-skb->data, clen);
+ data.sg_src = data.sg_dst = sg;
+
+ key = kmalloc(crypto_tfm_alg_ivsize(tfm) + esp->conf.key_len, GFP_ATOMIC);
+ if (!key)
+ goto err_out_free_sg;
+
+ iv = key + esp->conf.key_len;
+
+ if (esp->conf.ivlen) {
+ data.sg_key = &sg[nfrags - 2];
+ data.sg_iv = &sg[nfrags - 1];
+ data.sg_key_num = data.sg_iv_num = 1;
+ } else {
+ data.sg_key = &sg[nfrags - 1];
+ data.sg_iv = NULL;
+ data.sg_key_num = 1;
+ data.sg_iv_num = 0;
+ }
+
+ data.sg_src_num = data.sg_dst_num = nfrags - data.sg_key_num - data.sg_iv_num;
+
+ memcpy(key, esp->conf.key, esp->conf.key_len);
+ data.sg_key[0].offset = offset_in_page(key);
+ data.sg_key[0].length = esp->conf.key_len;
+ data.sg_key[0].page = virt_to_page(key);
+
+ if (esp->conf.ivlen) {
+ memcpy(iv, esp->conf.ivec, crypto_tfm_alg_ivsize(tfm));
+ data.sg_iv[0].offset = offset_in_page(iv);
+ data.sg_iv[0].length = crypto_tfm_alg_ivsize(tfm);
+ data.sg_iv[0].page = virt_to_page(iv);
+ }
+
+ data.priv = esp_output_async_prepare(x, skb);
+ if (!data.priv)
+ goto err_out_free_key;
+
+ s = crypto_session_alloc(&ci, &data);
+ if (!s)
+ goto err_out_free_ea;
+
+ return 0;
+
+err_out_free_ea:
+ kfree(data.priv);
+err_out_free_key:
+ kfree(key);
+err_out_free_sg:
+ kfree(sg);
+ goto sync_crypto;
+ } while (0);
+
+sync_crypto:
+#endif
if (esp->conf.ivlen)
crypto_cipher_set_iv(tfm, esp->conf.ivec, crypto_tfm_alg_ivsize(tfm));
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Evgeniy Polyakov @ 2005-06-04 10:00 UTC (permalink / raw)
To: Herbert Xu
Cc: Jeff Garzik, David S. Miller, James Morris,
Linux Crypto Mailing List, netdev
In-Reply-To: <20050604004201.GB20471@gondor.apana.org.au>
On Sat, 4 Jun 2005 10:42:01 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Hi Jeff:
>
> On Fri, Jun 03, 2005 at 08:02:52PM -0400, Jeff Garzik wrote:
> >
> > A standard feature of struct scatterlist is having the DMA mappings
> > right next to the kernel virtual address/length info. Drivers use the
> > arch-specific DMA-mapped part of struct scatterlist to fill the
> > hardware-specific descriptions with addresses and other info.
>
> Agreed.
>
> > Since you -will- have to DMA map buffers before passing them to
> > hardware, it seems like struct scatterlist is much more appropriate than
> > crypto_frag when dealing with hardware.
> >
> > For pure software implementations, I don't see why you can't just ignore
> > the extra fields that each arch puts into struct scatterlist.
>
> It depends on who is going to do the mapping. When we implement hardware
> crypto, the DMA mapping will be done either by the crypto layer or under
> it by the driver itself. So the crypto layer is certainly going to need
> the scatterlist structure.
>
> However, the users of the crypto layer (such as IPsec/dmcrypt) don't have
> to know about DMA at all. Therefore the data structure between the users
> and the crypto layer itself doesn't have to carry DMA information.
>
> Compare this with the block layer. Between the users of the block layer
> and the block layer itself you have the bio_vec structure which carries
> no DMA information. The scatterlist structure only comes into play after
> DMA mapping has been carried out under the block layer.
>
> So this is really a sort of bio_vec for crypto structures. The objective
> here is to make the structure as compact as possible to allow users to
> allocate it on the stack most of the time.
As far as I remember, IPsec has scterlists specially to _not_ remap
from any inner strucutre to scaterlist later.
Block layer was not designed in a such way because
there is no easy mapping in block cache into scaterlist
and bio_vec has much bigger usage than SA, so removing dma address
is suitable there.
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 9:58 UTC (permalink / raw)
To: Evgeniy Polyakov
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604135535.3cfb631f@zanzibar.2ka.mipt.ru>
On Sat, Jun 04, 2005 at 01:55:35PM +0400, Evgeniy Polyakov wrote:
>
> processing code. And you can not easily move away of SA lock due to
> synchronous problems with the same tfm.
This is not true. The tfm context contains no shared state apart
from the IV. As the IV can be specified through the *_iv functions,
this allows crypto API users to process the same cipher tfm on two
CPUs in parallel.
If you don't believe me just wait for my upcoming patches to IPsec.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Evgeniy Polyakov @ 2005-06-04 9:55 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <20050603234623.GA20088@gondor.apana.org.au>
On Sat, 4 Jun 2005 09:46:23 +1000
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Hi:
>
> I was looking at how we can move the IPsec input/output processing out
> of the critical section protected by the spin locks on the xfrm_state.
> This is useful because it would allow concurrent processing of IPsec
> packets for the same SA. It is also necessary if we're ever going to
> add support for asynchronous crypto to IPsec.
Asynchronous schemas already works without any changes to scaterlist
processing code. And you can not easily move away of SA lock due to
synchronous problems with the same tfm.
Existing asynchronous schemas do not use any shared object in SA,
only skb.
> The first requirement for this is that we need to stop using data that
> is shared across a single SA in the IPsec input/output routines. The
> biggest hurdle there as it stands is sgbuf in esp_data. This was
> introduced to reduce stack usage in esp_input/esp_output as sgbuf
> would consume up to 64 bytes of space.
No need to have it at all, I think.
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
^ permalink raw reply
* [git patches] 2.6.x net driver fixes
From: Jeff Garzik @ 2005-06-04 8:38 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: Netdev, Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
Please pull from the 'misc-fixes' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to obtain r8169 and 3c574_cs fixes. diffstat/shortlog/patch attached.
Jeff
[-- Attachment #2: netdev-2.6.txt --]
[-- Type: text/plain, Size: 3319 bytes --]
drivers/net/pcmcia/3c574_cs.c | 3 +++
drivers/net/r8169.c | 31 +++++++++++++++++++++++++------
2 files changed, 28 insertions(+), 6 deletions(-)
<jgarzik@pretzel.yyz.us>:
Automatic merge of /spare/repo/netdev-2.6 branch r8169-fix
Automatic merge of rsync://rsync.kernel.org/.../torvalds/linux-2.6.git branch HEAD
Daniel Ritz <daniel.ritz@gmx.ch>:
3c574_cs: disable interrupts in el3_close
Francois Romieu <romieu@fr.zoreil.com>:
[PATCH] r8169: incoming frame length check
diff --git a/drivers/net/pcmcia/3c574_cs.c b/drivers/net/pcmcia/3c574_cs.c
--- a/drivers/net/pcmcia/3c574_cs.c
+++ b/drivers/net/pcmcia/3c574_cs.c
@@ -1274,6 +1274,9 @@ static int el3_close(struct net_device *
spin_lock_irqsave(&lp->window_lock, flags);
update_stats(dev);
spin_unlock_irqrestore(&lp->window_lock, flags);
+
+ /* force interrupts off */
+ outw(SetIntrEnb | 0x0000, ioaddr + EL3_CMD);
}
link->open--;
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1585,8 +1585,8 @@ rtl8169_hw_start(struct net_device *dev)
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
RTL_W8(EarlyTxThres, EarlyTxThld);
- /* For gigabit rtl8169, MTU + header + CRC + VLAN */
- RTL_W16(RxMaxSize, tp->rx_buf_sz);
+ /* Low hurts. Let's disable the filtering. */
+ RTL_W16(RxMaxSize, 16383);
/* Set Rx Config register */
i = rtl8169_rx_config |
@@ -2127,6 +2127,11 @@ rtl8169_tx_interrupt(struct net_device *
}
}
+static inline int rtl8169_fragmented_frame(u32 status)
+{
+ return (status & (FirstFrag | LastFrag)) != (FirstFrag | LastFrag);
+}
+
static inline void rtl8169_rx_csum(struct sk_buff *skb, struct RxDesc *desc)
{
u32 opts1 = le32_to_cpu(desc->opts1);
@@ -2177,27 +2182,41 @@ rtl8169_rx_interrupt(struct net_device *
while (rx_left > 0) {
unsigned int entry = cur_rx % NUM_RX_DESC;
+ struct RxDesc *desc = tp->RxDescArray + entry;
u32 status;
rmb();
- status = le32_to_cpu(tp->RxDescArray[entry].opts1);
+ status = le32_to_cpu(desc->opts1);
if (status & DescOwn)
break;
if (status & RxRES) {
- printk(KERN_INFO "%s: Rx ERROR!!!\n", dev->name);
+ printk(KERN_INFO "%s: Rx ERROR. status = %08x\n",
+ dev->name, status);
tp->stats.rx_errors++;
if (status & (RxRWT | RxRUNT))
tp->stats.rx_length_errors++;
if (status & RxCRC)
tp->stats.rx_crc_errors++;
+ rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
} else {
- struct RxDesc *desc = tp->RxDescArray + entry;
struct sk_buff *skb = tp->Rx_skbuff[entry];
int pkt_size = (status & 0x00001FFF) - 4;
void (*pci_action)(struct pci_dev *, dma_addr_t,
size_t, int) = pci_dma_sync_single_for_device;
+ /*
+ * The driver does not support incoming fragmented
+ * frames. They are seen as a symptom of over-mtu
+ * sized frames.
+ */
+ if (unlikely(rtl8169_fragmented_frame(status))) {
+ tp->stats.rx_dropped++;
+ tp->stats.rx_length_errors++;
+ rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
+ goto move_on;
+ }
+
rtl8169_rx_csum(skb, desc);
pci_dma_sync_single_for_cpu(tp->pci_dev,
@@ -2224,7 +2243,7 @@ rtl8169_rx_interrupt(struct net_device *
tp->stats.rx_bytes += pkt_size;
tp->stats.rx_packets++;
}
-
+move_on:
cur_rx++;
rx_left--;
}
^ permalink raw reply
* Re: [6/9] ieee80211: ethernet independency
From: Jouni Malinen @ 2005-06-04 5:45 UTC (permalink / raw)
To: Jiri Benc; +Cc: NetDev, Jeff Garzik, Jirka Bohac
In-Reply-To: <20050603183418.58c47b0c@griffin.suse.cz>
On Fri, Jun 03, 2005 at 06:34:18PM +0200, Jiri Benc wrote:
> Makes the 802.11 layer independent of ethernet. (The previous implementation
> had the ethernet headers built by the ethernet layer and then parsed them and
> rebuilt them into 802.11 headers.)
Many (most?) parts of this change seems to be only for client (managed
and ad-hoc) modes. Has anyone had chance to go through what would be
needed for AP (master mode) and WDS links? What about extra bytes added
for QoS information (IEEE 802.11e/WMM)? Are there places here that will
not handle variable length header nicely?
I haven't yet looked into details, but could someone explain what a user
space program needs to do when receiving or sending packets with packet
socket from a 802.11 netdev (e.g., ethertype=EAPOL)? Let's say in the
"worst case" scenario: QoS enabled and pairwise keys configured and
4-address WDS link (i.e., 32-byte IEEE 802.11 header).
Will the user space program need to parse (and generate) the IEEE 802.11
header, including the knowledge of four addresses and QoS data, and SNAP
header? Packet socket with SOCK_DGRAM could otherwise be one way of
doing this, but sockaddr_ll does not have places for many parameters..
Many of these questions are not really specifically related to this
patch, but I haven't seen a good answer to these open areas (well, at
least to me) so far.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 5:33 UTC (permalink / raw)
To: James Morris
Cc: Jeff Garzik, David S. Miller, Linux Crypto Mailing List, netdev
In-Reply-To: <Xine.LNX.4.44.0506040122210.11356-100000@thoron.boston.redhat.com>
On Sat, Jun 04, 2005 at 01:23:55AM -0400, James Morris wrote:
> On Sat, 4 Jun 2005, Herbert Xu wrote:
>
> > Thanks James. What do you think about eating up 32 bytes on the
> > stack in esp_input/esp_output?
>
> Sounds like a low price to pay, given the general overhead of ipsec.
I agree with you on the stack usage. BTW, we can now pump 5Gb/s
through the Crypto API using a 1Ghz VIA CPU with the Padlock so
encryption is no longer necessarily the slowest piece along the
pipeline :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ieee80211: Update generic definitions to latest specs.
From: Jouni Malinen @ 2005-06-04 5:29 UTC (permalink / raw)
To: Jiri Benc; +Cc: gwingerde, netdev, jbohac
In-Reply-To: <20050603113343.55d19cfc@griffin.suse.cz>
On Fri, Jun 03, 2005 at 11:33:43AM +0200, Jiri Benc wrote:
> and so on. Also WLAN_STATUS_ASSOC_DENIED_NOSHORT seems to be acceptable
> for me.
That would be just asking for problems. IEEE 802.11 uses "short" in
number of terms and two of them happen to be already part of
capabilities negotatiation (short preamble and short slot time) and both
have status codes for rejecting association.. In other words, the
constants/enums better include PREAMBLE and SLOTTIME in the name.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: James Morris @ 2005-06-04 5:23 UTC (permalink / raw)
To: Herbert Xu
Cc: Jeff Garzik, David S. Miller, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604045119.GA25270@gondor.apana.org.au>
On Sat, 4 Jun 2005, Herbert Xu wrote:
> Thanks James. What do you think about eating up 32 bytes on the
> stack in esp_input/esp_output?
Sounds like a low price to pay, given the general overhead of ipsec.
> In fact, how did we come up with the number of four frags? Why wouldn't
> say two frags do for most users or perhaps even one?
I don't know where that came from.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: Automated linux kernel testing results
From: Jonathan Day @ 2005-06-04 5:01 UTC (permalink / raw)
To: Nivedita Singhvi, netdev
In-Reply-To: <42A0F3B4.1060601@us.ibm.com>
I am very impressed, especially as it sounds as though
a lot more tests exist (he talks of only pushing small
amounts of data to kernel.org) and a lot more are
going to be added.
It seems to me that there are a lot of disparate test
suites out there - some test the APIs, some benchmark
the performance, some validate the state at the end,
some verify that the source obeys expected rules.
What I have not (yet) seen is any work on relating the
results. Is a bug in the design? The implementation?
Some combination thereof? Is something correctly
written but not functioning because something it
depends on isn't working correctly?
It would even be useful if we could cross-reference
some of the benchmarks with the Linux graphing
project, so that we could see how the complexity of
the tested component differs between versions and
variants. (A small degredation in performance, if
related to a large increase in necessary
sophistication, is not necessarily that bad. The same
performance drop, if related to a massive
simplification of the design, is an indication of a
serious problem.)
Test suites are necessary. Test suites are great.
Anyone working on a test suite deserves many kudos and
much praise. Test suites that are relatable enough
that you can see the same problem from different
angles -- those are worth their printout weight in
gold.
--- Nivedita Singhvi <niv@us.ibm.com> wrote:
> For those who don't read lkml, I thought I'd point
> to
> Martin Bligh's post regarding automated testing
> being
> set up, since some people on this list were
> interested.
>
>
http://marc.theaimsgroup.com/?l=linux-kernel&m=111775021327595&w=2
>
> Networking tests are in plan...
>
> thanks,
> Nivedita
>
> --------------------------
>
> OK, I've finally got this to the point where I can
> publish it.
>
>
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html
>
>
> Currently it builds and boots any mainline, -mjb,
> -mm kernel within
> about 15 minutes of release. runs dbench, tbench,
> kernbench, reaim and fsx.
> Currently I'm using a 4x AMD64 box, a 16x NUMA-Q, 4x
> NUMA-Q, 32x x440
> (ia32)
> PPC64 Power 5 LPAR, PPC64 Power 4 LPAR, and PPC64
> Power 4 bare metal
> system.
> The config files it uses are linked by the machine
> names in the column
> headers.
>
> Thanks to all the other IBM people who've worked on
> the ABAT test system
> that this stuff relies on - too many to list, but
> especially Andy, Adam,
> and Enrique, who have fixed endless bugs, and put up
> with my incessant
> bitching about it all not working as it should ;-)
>
> Clicking on the failure ones error codes should take
> you to somewhere
> vaguely helpful to diagnose it. Clicking on the job
> number just below
> that takes you to the info I'm publishing right now,
> which should
> include perf results and profiles, etc. I'll add
> graphs, etc later,
> comparing performance across kernels (I have them
> ... just not automated).
>
>
>
>
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 4:51 UTC (permalink / raw)
To: James Morris
Cc: Jeff Garzik, David S. Miller, Linux Crypto Mailing List, netdev
In-Reply-To: <Xine.LNX.4.44.0506040039190.11329-100000@thoron.boston.redhat.com>
On Sat, Jun 04, 2005 at 12:39:41AM -0400, James Morris wrote:
> On Sat, 4 Jun 2005, Herbert Xu wrote:
>
> > So this is really a sort of bio_vec for crypto structures. The objective
> > here is to make the structure as compact as possible to allow users to
> > allocate it on the stack most of the time.
>
> Seems like a good idea to me.
Thanks James. What do you think about eating up 32 bytes on the
stack in esp_input/esp_output?
In fact, how did we come up with the number of four frags? Why wouldn't
say two frags do for most users or perhaps even one?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: James Morris @ 2005-06-04 4:39 UTC (permalink / raw)
To: Herbert Xu
Cc: Jeff Garzik, David S. Miller, Linux Crypto Mailing List, netdev
In-Reply-To: <20050604004201.GB20471@gondor.apana.org.au>
On Sat, 4 Jun 2005, Herbert Xu wrote:
> So this is really a sort of bio_vec for crypto structures. The objective
> here is to make the structure as compact as possible to allow users to
> allocate it on the stack most of the time.
Seems like a good idea to me.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: [RFC] Replace scatterlist with crypto_frag
From: Herbert Xu @ 2005-06-04 0:42 UTC (permalink / raw)
To: Jeff Garzik
Cc: David S. Miller, James Morris, Linux Crypto Mailing List, netdev
In-Reply-To: <42A0EFAC.7070609@pobox.com>
Hi Jeff:
On Fri, Jun 03, 2005 at 08:02:52PM -0400, Jeff Garzik wrote:
>
> A standard feature of struct scatterlist is having the DMA mappings
> right next to the kernel virtual address/length info. Drivers use the
> arch-specific DMA-mapped part of struct scatterlist to fill the
> hardware-specific descriptions with addresses and other info.
Agreed.
> Since you -will- have to DMA map buffers before passing them to
> hardware, it seems like struct scatterlist is much more appropriate than
> crypto_frag when dealing with hardware.
>
> For pure software implementations, I don't see why you can't just ignore
> the extra fields that each arch puts into struct scatterlist.
It depends on who is going to do the mapping. When we implement hardware
crypto, the DMA mapping will be done either by the crypto layer or under
it by the driver itself. So the crypto layer is certainly going to need
the scatterlist structure.
However, the users of the crypto layer (such as IPsec/dmcrypt) don't have
to know about DMA at all. Therefore the data structure between the users
and the crypto layer itself doesn't have to carry DMA information.
Compare this with the block layer. Between the users of the block layer
and the block layer itself you have the bio_vec structure which carries
no DMA information. The scatterlist structure only comes into play after
DMA mapping has been carried out under the block layer.
So this is really a sort of bio_vec for crypto structures. The objective
here is to make the structure as compact as possible to allow users to
allocate it on the stack most of the time.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Unitialized queue_lock oops?
From: Phil Oester @ 2005-06-04 0:38 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20050604003441.GA20471@gondor.apana.org.au>
On Sat, Jun 04, 2005 at 10:34:41AM +1000, Herbert Xu wrote:
> On Fri, Jun 03, 2005 at 05:00:46PM -0700, Phil Oester wrote:
> >
> > Yes, default qdisc. Interesting that 2.6.10 is rock solid on the same
> > hardware...oh well.
>
> Well if you do have the time feel free to keep searching back to 2.6.10.
> Even though I'd say that this is most likely to turn out to be a hardware
> problem, there is no telling what you might find along the way.
>
> At least it might tell us what sort of hardware problems would result in
> only networking crashes :) If this were your average hardware problem
> I'd have expected to see crashes all over the place, especially under
> fs/ and mm/.
Ok, how bout next week I adjust OSPF costs to make my secondary firewall
primary, and see if I still have problems? At least then we can put the
hardware problem theory behind us...
Phil
^ permalink raw reply
* Re: Unitialized queue_lock oops?
From: Herbert Xu @ 2005-06-04 0:34 UTC (permalink / raw)
To: Phil Oester; +Cc: netdev
In-Reply-To: <20050604000046.GA29438@linuxace.com>
On Fri, Jun 03, 2005 at 05:00:46PM -0700, Phil Oester wrote:
>
> Yes, default qdisc. Interesting that 2.6.10 is rock solid on the same
> hardware...oh well.
Well if you do have the time feel free to keep searching back to 2.6.10.
Even though I'd say that this is most likely to turn out to be a hardware
problem, there is no telling what you might find along the way.
At least it might tell us what sort of hardware problems would result in
only networking crashes :) If this were your average hardware problem
I'd have expected to see crashes all over the place, especially under
fs/ and mm/.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Michael Chan @ 2005-06-04 0:25 UTC (permalink / raw)
To: hadi
Cc: Lennert Buytenhek, David S. Miller, mitch.a.williams,
john.ronciak, jdmason, shemminger, netdev, Robert.Olsson,
ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <1117837798.6266.25.camel@localhost.localdomain>
On Fri, 2005-06-03 at 18:29 -0400, jamal wrote:
> On Fri, 2005-03-06 at 13:35 -0700, Michael Chan wrote:
>
> > By the way, in tg3 there is a buffer replenishment threshold programmed
> > to the chip and is currently set at rx_pending / 8 (200/8 = 25). This
> > means that the chip will replenish 25 rx buffers at a time.
> >
>
> So when you write the MMIO, 25 buffers are replenished or is this auto
> magically happening in the background? Sounds like a neat feature either
> way.
>
The MMIO writes a cumulative producer index of new rx descriptors in the
ring. As the chip requires new buffers for rx packets, it will DMA 25 of
these rx descriptors at a time up to the producer index.
^ permalink raw reply
* Automated linux kernel testing results
From: Nivedita Singhvi @ 2005-06-04 0:20 UTC (permalink / raw)
To: netdev
For those who don't read lkml, I thought I'd point to
Martin Bligh's post regarding automated testing being
set up, since some people on this list were interested.
http://marc.theaimsgroup.com/?l=linux-kernel&m=111775021327595&w=2
Networking tests are in plan...
thanks,
Nivedita
--------------------------
OK, I've finally got this to the point where I can publish it.
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/regression_matrix.html
Currently it builds and boots any mainline, -mjb, -mm kernel within
about 15 minutes of release. runs dbench, tbench, kernbench, reaim and fsx.
Currently I'm using a 4x AMD64 box, a 16x NUMA-Q, 4x NUMA-Q, 32x x440
(ia32)
PPC64 Power 5 LPAR, PPC64 Power 4 LPAR, and PPC64 Power 4 bare metal
system.
The config files it uses are linked by the machine names in the column
headers.
Thanks to all the other IBM people who've worked on the ABAT test system
that this stuff relies on - too many to list, but especially Andy, Adam,
and Enrique, who have fixed endless bugs, and put up with my incessant
bitching about it all not working as it should ;-)
Clicking on the failure ones error codes should take you to somewhere
vaguely helpful to diagnose it. Clicking on the job number just below
that takes you to the info I'm publishing right now, which should
include perf results and profiles, etc. I'll add graphs, etc later,
comparing performance across kernels (I have them ... just not automated).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox