Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+textsearch\s+infrastructure\s+et\s+al\s+v2\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+textsearch\s+infrastructure\s+et\s+al\s+v2\s*$/: 22 ]

Total 22 documents matching your query.

1. [RFC] textsearch infrastructure et al v2 (score: 1): Author: <christoph@xxxxxxxxxxx>; Date: Sat, 28 May 2005 00:47:25 +0200; Dave, I'm going through another RFC round to hopefully get some comments on the notes below. I'm not yet satistifed with the core infrastructure wrt to non-linear data, especially for complex cases s; /archives/netdev/2005-05/msg01164.html (9,604 bytes)
2. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: xx>; Date: Sat, 28 May 2005 07:59:41 -0400; I dont have opinions on this since you and Pablo seem to agree on it. What I remember is that libssearch (or whatever that thing Harald was looking at) did it differently (callback invoked and it ret; /archives/netdev/2005-05/msg01190.html (12,014 bytes)
3. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: <tgraf@xxxxxxx>; Date: Sat, 28 May 2005 14:35:42 +0200; * jamal <1117281581.6251.68.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-28 07:59 Same for my infrastructure with the difference that libqsearch uses a single input buffer so no chance for non-linear data. T; /archives/netdev/2005-05/msg01193.html (12,845 bytes)
4. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: xxxxxxxxxx>; Date: Sat, 28 May 2005 14:56:37 +0200; Thomas Graf wrote: * jamal <1117281581.6251.68.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-28 07:59 I dont have opinions on this since you and Pablo seem to agree on it. to be frank, i'm still willing to pr; /archives/netdev/2005-05/msg01194.html (14,424 bytes)
5. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: xxxxxx>; Date: Sat, 28 May 2005 14:58:37 +0200; Pablo Neira wrote: Same for my infrastructure with the difference that libqsearch uses a single input buffer so no chance for non-linear data. hm, i don't understand quite well, i bet that libqsearch; /archives/netdev/2005-05/msg01195.html (10,726 bytes)
6. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: xx>; Date: Sat, 28 May 2005 14:58:51 +0200; Pablo Neira wrote: Same for my infrastructure with the difference that libqsearch uses a single input buffer so no chance for non-linear data. hm, i don't understand quite well, i bet that libqsearch; /archives/netdev/2005-05/msg01196.html (10,650 bytes)
7. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: pablo@xxxxxxxxxxx>; Date: Sat, 28 May 2005 15:58:13 +0200; * Pablo Neira <42986A85.9060001@xxxxxxxxxxx> 2005-05-28 14:56 I'll rephrase, libqsearch, according to my understanding, is not able to do optimized scanning over borders, i.e. it uses the same naive; /archives/netdev/2005-05/msg01199.html (12,617 bytes)
8. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: n@xxxxxxxxxxxx>; Date: Tue, 31 May 2005 14:56:27 -0700 (PDT); You could just fetch "windows" of data. You can define this window to be 32 bytes, or whatever. Then you use skb_copy_data() into this 32 byte window scratch pad the text searcher uses, and you're do; /archives/netdev/2005-05/msg01254.html (9,158 bytes)
9. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: @xxxxxxxxxxxxx>; Date: Tue, 31 May 2005 15:05:38 -0700 (PDT); This case got converted into what skb_copy_bits() was probably meant to be, skb_header_pointer(). The idea is, if it's linear in the SKB already (headers almost certainly are) just pass back the poin; /archives/netdev/2005-05/msg01255.html (9,921 bytes)
10. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: <davem@xxxxxxxxxxxxx>; Date: Wed, 1 Jun 2005 00:44:39 +0200; * David S. Miller <20050531.145627.85412348.davem@xxxxxxxxxxxxx> 2005-05-31 Heh, I had something like this in mind. Well, basically the current behaviour is not different except that the window is va; /archives/netdev/2005-05/msg01269.html (9,721 bytes)
11. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: raf@xxxxxxx>; Date: Tue, 31 May 2005 15:50:37 -0700 (PDT); Sounds good.; /archives/netdev/2005-05/msg01272.html (8,965 bytes)
12. [RFC] textsearch infrastructure et al v2 (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sat, 28 May 2005 00:47:25 +0200; Dave, I'm going through another RFC round to hopefully get some comments on the notes below. I'm not yet satistifed with the core infrastructure wrt to non-linear data, especially for complex cases s; /archives/netdev/2005-05/msg02453.html (9,604 bytes)
13. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Sat, 28 May 2005 07:59:41 -0400; I dont have opinions on this since you and Pablo seem to agree on it. What I remember is that libssearch (or whatever that thing Harald was looking at) did it differently (callback invoked and it ret; /archives/netdev/2005-05/msg02479.html (12,074 bytes)
14. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sat, 28 May 2005 14:35:42 +0200; * jamal <1117281581.6251.68.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-28 07:59 Same for my infrastructure with the difference that libqsearch uses a single input buffer so no chance for non-linear data. T; /archives/netdev/2005-05/msg02482.html (12,954 bytes)
15. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: Pablo Neira <pablo@xxxxxxxxxxx>; Date: Sat, 28 May 2005 14:56:37 +0200; I dont have opinions on this since you and Pablo seem to agree on it. to be frank, i'm still willing to propose some changes to Thomas, I'll do soon since he's pulled my ear with this second rfc req; /archives/netdev/2005-05/msg02483.html (14,819 bytes)
16. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: Pablo Neira <pablo@xxxxxxxxxxx>; Date: Sat, 28 May 2005 14:58:37 +0200; hm, i don't understand quite well, i bet that libqsearch was already fragment-aware. Anyway the main difference is that libqsearch wasn't designed to be used in user space so, for example, it needed; /archives/netdev/2005-05/msg02484.html (10,941 bytes)
17. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: Pablo Neira <pablo@xxxxxxxxxxx>; Date: Sat, 28 May 2005 14:58:51 +0200; hm, i don't understand quite well, i bet that libqsearch was already fragment-aware. Anyway the main difference is that libqsearch wasn't designed to be used in user space so, for example, it needed; /archives/netdev/2005-05/msg02485.html (10,865 bytes)
18. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sat, 28 May 2005 15:58:13 +0200; * Pablo Neira <42986A85.9060001@xxxxxxxxxxx> 2005-05-28 14:56 I'll rephrase, libqsearch, according to my understanding, is not able to do optimized scanning over borders, i.e. it uses the same naive; /archives/netdev/2005-05/msg02488.html (12,757 bytes)
19. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 31 May 2005 14:56:27 -0700 (PDT); You could just fetch "windows" of data. You can define this window to be 32 bytes, or whatever. Then you use skb_copy_data() into this 32 byte window scratch pad the text searcher uses, and you're do; /archives/netdev/2005-05/msg02543.html (9,218 bytes)
20. Re: [RFC] textsearch infrastructure et al v2 (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 31 May 2005 15:05:38 -0700 (PDT); This case got converted into what skb_copy_bits() was probably meant to be, skb_header_pointer(). The idea is, if it's linear in the SKB already (headers almost certainly are) just pass back the poin; /archives/netdev/2005-05/msg02544.html (10,031 bytes)

Current List: 1 - 20
Page: [1] [2]