Re: question about softirqs

d to kernel threads (work queue actually). At least that's how tasklet behaved compared to work queue 1.5 years ago in the simplest and quite naive test where tasklet/work rescheduled iself number of times: http://marc.info/?l=linux-crypto-vger&m=119462472517405&w=2 --

Re: RFC: issues concerning the next NAPI interface

pts will not gain anything (actually it is what is supposed to be dropped noticebly). -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

Q_NONE; > +} Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

lock_irqsave() is used in some other places, but not in interrupt handler itself. -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

t? priv->status is accessed from tasklets, although readonly, but that rises a red flag... Also callback invocation tasklet drops the lock around callback, during that time cached status and priv itself (and tail like in two simultaneous flushes) could change (or not?) --

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

n a per > descriptor basis. It forwards this descriptor done vs. error status to > the callback. > > priv itself won't change; it's uniquely associated to the device. I meant descriptor hdr value accessed via it - can it be c

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

a non-null request->desc (under lock) before > the hdr value is accessed ensures this doesn't happen. But can it be changed? You write to it without lock, but read under the one (different for each channel though), so it attracted atten

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

esult can be false. Or this is not an issue? -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver

of lock (as is > commented). Note desc gets assigned NULL prior to releasing the lock, > after copying its contents to saved_req. Excellent! It looks like there are no more issues and second version fixed found problem place. -- Evgeniy Polyakov

Re: [PATCH 2/2] eHEA: Receive SKB Aggregation, generic LRO helper functions

lperfunctions. > What do you think about putting them into /net/ipv4/inet_lro.c and > /include/linux/inet_lro.h ? The more I think, the more it looks as appropriate to be used by all hardware drivers with proper API. As far as I recall this is third impl

Re: [RFC 1/3] lro: Generic LRO for TCP traffic

et_lro_desc *lro_desc; > +struct iphdr *iph; > +struct tcphdr *tcph; > + > + if (!lro_mgr->get_ip_tcp_hdr > + || lro_mgr->get_ip_tcp_hdr(skb, &iph, &tcph, priv)) > + goto out; > + > + lro_desc = lro_get_desc(lro_mgr, lro_mgr->lro_arr, iph, tcph); > + if (!lro_desc) > + goto out; There is no protection of the descriptor array from accessing from different CPUs. Is it forbidden to share net_lro_mgr structure? -- Evgeniy Polyakov ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC 1/1] lro: Generic Large Receive Offload for TCP traffic

void *mac_hdr, > + int hlen) > +{ > + struct sk_buff *skb; > +struct skb_frag_struct *skb_frags; > + int data_len = len; The same. > + skb = netdev_alloc_skb(lro_mgr->dev, hlen); &