Sorry for not replying to these... eric wang wrote: > hi Darren > > Following are my comments on the HOOKAPI implementation and documentation > > 1) It is desired to have a function that can reinject packets back into > selected hook. This function is useful when a callback needs to perform > delayed or time-consuming operations, and needs to steal a packet and process > it in a separate thread or user land. Currently net_inject can be used to > send packets out, but net_inject has several limitations, such as by-pass > other hook callbacks and does not work in inbound packets (?). >
We cannot do this easily, yet, because there is no place to store the state of a packet's processing. When we refactor the IP datapath, we will look at what can be done to support this. > 2) please explain how memory / mblk are managed. The documentation / man > page should help users answer questions such as: does callback need to free a > packet if it is blocked? can a callback store it and process it later? can > a callback create a new packet then discard the old packet or send both old > and new packets? > If the callback returns non-zero and the packet is not free'd by the callback then it will be dropped. The packet can be stored and processed later. The current packet can be replaced with a new one, but it cannot introduce another. > 3) Is it possible to add some field in hook event to pass user-defined data > between callbacks? Since it is not possible to pass user-data by mblk, I am > hoping that HOOKAPI can provide an alternative solution... > When an event is registered, it is possible to supply an extra arg to pass into the callback. This can be a pointer to whatever. If instead you're looking for the means to associate a piece of data with a packet with callback A and retrieve it with callback B later, that is not currently possible. There are some complexities that need to be answered, such as what happens if the packet is free'd by something else? > 4) is it useful to provide an additional callback or event to notice callback > order change? For example, if a callback is defined as "HH_AFTER ipfilter" > but later ipfilter is removed, is it useful to notice the callback this event? > See my comments elsewhere. > 5) If a registration call failed because of order issue (e.g., hint not > found), does net_callback_register return a error code, e.g., so user can try > an alternative order? The man page shows the registration call only return > success or failure, but not specific reason > The manual page is not showing as much detail as it should, it will return an error such as ESRCH if the hint isn't found. > 6) can you give more detail on how net_inject mode works? What is > NI_QUEUE_IN and NI_QUEUE_OUT? The explanation is a little bit confusing... > > QUEUE_IN - put the packet on a queue and then call ip_input(), mimicking it being receive by IP from a driver. QUEUE_OUT - put the packet on a queue and then call ip_output(), mimicking it being sent by UDP, etc. Darren _______________________________________________ networking-discuss mailing list [email protected]
