I noticed the other email carrying a patch. Let me respond to this email and hopefully that will address the patch.
On Thu, 2006-29-06 at 10:51 +0200, Thomas Graf wrote: > * jamal <[EMAIL PROTECTED]> 2006-06-28 09:46 [..] > I disagree, iflink information is bogus once we start redirecting. After redirecting, iflink is "available" i.e it doesnt make any more sense and therefore it should be (ab)usable to carry other info. But the more i think about it, using skb->dev is just fine for finding the device you are looking for even when it gets redirected. I am assuming you still want to find out - in the case of a topology which constitutes more than one netdevice - the second last netdevice, correct? > > > > Can you achieve the same by binding to any arbitrary netdevice? If you > > can then i would agree. > > It was your request to not update input_dev in netif_receive_skb() > but rather have each netdevice handle it manually. For good reasons of course. note: you didnt answer the question i asked, but probably the answer doesnt matter. > What's currently > done in ifb: > > skb->dev = skb->input_dev; > skb->input_dev = dev; > > Confusing, isn't it? not at all. Let me explain the design intent further below. > I really don't get input_dev/iif is supposed to > be updated in ifb. If a packet is to be redirected, the mirred action > shall take care of providing this information to the next netdevice. ifb is a special purpose device. Think of it as a redirector, or injector if you want a better noun. If you are going to inject packets back to the stack at arbitrary points, then you need to reflect that in the packet metadata implying where it came from. Likewise if you are going to redirect packets into arbitrary points in the stack (as mirred does), you need to do the same. I dont know if that makes sense. > My additional request is to provide a flag to disable this for special > purposes not hurting anyone. I am failing to see the purpose. With all due respect, you are changing the design intent, Thomas. I know your intent is noble in trying to save the 32 bits on 64 bit machines (at least thats where your patch seems to have started) but the cost:benefit ratio as i have pointed out is unreasonable. If you can meet the requirements i have specified (I am leaving them below) i will be a happy camper. > > The challenge is this, and if you can solve it we would be fine: > > - I need to access both the input_dev and dev and their metadata. > > I could clearly find them by their ifindices and then reference them > > after that. For performance reasons that is not optimal in the fast > > path. > So just we are clear: I have strong desire to save compute rather than than saving 32 bits per skb on 64 bit machine. > Nice, you forget that while redirecting the device pointed to by > input_dev can disappear leaving behind an illegal reference. We have had this discussion before - that is resolvable via dev_put/hold. > The purpose of this patch is to fix this. Appreciated - but can you do it without replacing the input_dev? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
