On Mon, Mar 17, 2008 at 5:04 PM, Johannes Berg<johannes@xxxxxxxxxxxxxxxx> wrote:>> > This is only in RX side. Each AC (access category) queue transmit in> > it's own rate. For example VO trasmitts more packets then BE. So you> > might get into case in receive site that VO packets are already on> > wraparound side while BE are still using 'old' phase1.> > Best remedy is to keep phase1 per each AC.> >> > > but I think this is not too important as> > > non-matching will just be done in software.> >> > Correct, this should happen only for short period of time that ph1> > doesn't match for each AC queue.>> Right, in software we can keep a phase1 per AC but we don't need to in> hardware since that's just the optimisation.
Correct, I'm just not sure how it's done for bcom cards.>> > > However, bcom firmware wants> > > to have just the phase 1 key, and as far as I can tell the driver can't,> > > even with your patches, obtain a phase 1 key for TX.> >> > Not sure these cases are symmetric. You have to have phase1 ready in> > HW before you transmit the packet> > Phase1 need to be adhered to a packet that causes wraparound unlike RX> > that you can fall back to SW decryption> > In TX there is no way back.>> Good point. So then for Broadcom we actually need to update phase1 in> hardware when it changes on TX and not bother with RX at all, we'll fall> back to software in that case.
Eventually you want to update RX phase1 key into HW so you get yourCPU utilization where it have to be, right?
>> > > > > How about instead we add a new "update_tkip_key()" callback that takes> > > > > exactly the required parameters? It should also give the> > > > > hardware-key-index so that the driver has less work to do.> > > >> > > > It's viable but I actually prefer not opening too many interfaces.> > > > Please give me some more detailed sketch how do you see that and we> > > > sure get to some acceptable solution.> > >> > > Yes, I would prefer not having that many interfaces as well, but I don't> > > think shoehorning it into the set_key() callback is a good idea because> > > (a) you add fields to the key conf structure that are only used for> > > the tkip stuff and only valid in some calls> > > (b) the patch breaks the set_key() interface's symmetry> > >> > > A new callback update_tkip_key could look like this:> > >> > > void update_tkip_phase1key(hw, keyconf, iv32, p1key)> >> > What about> > enum tkip_update_flags {> > TKIP_PH1_TX_KEY> > TKIP_PH1_RX_KEY> > TKIP_PH2_TX_KEY> > TKIP_PH2_RX_KEY -- actually no need for any driver.> > }> > update_tkip_key(hw, keyconf , iv32, flag, key)> >> > But I'm not sure about this... see above/belove> >> > > The IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID flag would go away, and the> > > new callback would be invoked right from where the phase1 key is> > > calculated.> >> > Sure again I'm not sure this is symmetric - For TX it would be safer> > to do pull mode otherwise it can get out of sync.>> True. Hence, since phase2rx is not really useful, we don't actually need> any sort of update flags when we do the TX keys in pull mode, which I> prefer anyway.>>> > > I'm not exactly sure whether one needs a phase1 key for RX and one for> > > TX right now, but if so a direction flag should be added?> >> > Phase1 for TX and RX are not the same, again because of the simple> > reasone that number of transmitted and received packet is not the> > same.>> Hm, right. But if we go for pull mode for TX, we only need to have push> mode for the phase1 rx key when that changes, no?
Emmanuel has prepared patches for TX pull mode (phase2 only for now) .If this OK wiith I will resend the whole TKIP series with this change,leaving RX in pull mode.We can do little effort to add pulling phase1 only but we cannot really test it.
ThanksTomas��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
