Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+ematch\s+API\,\s+u32\s+ematch\,\s+nbyte\s+ematch\,\s+basic\s+classifier\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+ematch\s+API\,\s+u32\s+ematch\,\s+nbyte\s+ematch\,\s+basic\s+classifier\s*$/: 54 ]

Total 54 documents matching your query.

1. [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Mon, 3 Jan 2005 13:56:35 +0100; Jamal et al, I attached 4 patches of a first ematch implementation. Comments and suggestions very much appreciated. Compiles but untested. Patch 1: ematch API API visible to classifier: tcf_em_tree_v; /archives/netdev/2005-01/msg00028.html (11,765 bytes)
2. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 03 Jan 2005 23:13:48 -0500; struct tcf_ematch_hdr { __u16 handle; __u16 matchID; __u16 kind; __u8 flags; __u8 pad; /* currently unused */ }; you need both matchID and handle? struct tcf_ematch { struct tcf_ematch_hdr hdr; struc; /archives/netdev/2005-01/msg00054.html (14,589 bytes)
3. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 4 Jan 2005 13:03:33 +0100; * jamal <1104812028.1085.50.camel@xxxxxxxxxxxxxxxx> 2005-01-03 23:13 No, handle is yet unused and I think we can screw it again. Correct, I wanted to avoid having to do transformations but it would s; /archives/netdev/2005-01/msg00059.html (14,928 bytes)
4. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 4 Jan 2005 13:27:38 +0100; * jamal <1104812028.1085.50.camel@xxxxxxxxxxxxxxxx> 2005-01-03 23:13 Might be worth to mention the motivation for this. fw and u32 will definitely perform much better on complex setups but many do no; /archives/netdev/2005-01/msg00060.html (10,558 bytes)
5. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 04 Jan 2005 08:19:13 -0500; My thinking is: It doesnt have to be simple 32 bit data. If i pass you a struct and tell you what length it is, then you as the classifier dont know need to know anything about it. You just store mys; /archives/netdev/2005-01/msg00061.html (11,935 bytes)
6. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 04 Jan 2005 08:22:15 -0500; agreed. I am pretty sure someone who knows u32 well can outperform you (in the scenarios where u32 works using AND etc). Start hitting 50K rules then lets talk ;-> If your intent is to write an ematc; /archives/netdev/2005-01/msg00062.html (11,675 bytes)
7. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 4 Jan 2005 14:41:26 +0100; * jamal <1104844935.1085.103.camel@xxxxxxxxxxxxxxxx> 2005-01-04 08:22 Sure but I'd call a filter with 50K ANDed rules an unlikely scenario ;-> In most cases logic will beat brute force. I used to hav; /archives/netdev/2005-01/msg00063.html (11,552 bytes)
8. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 4 Jan 2005 14:46:29 +0100; * jamal <1104844753.1085.99.camel@xxxxxxxxxxxxxxxx> 2005-01-04 08:19 That's exactly how it is, basically the logic is: if (ops->change) { err = ops->change(tp, data, datalen, m); if (err < 0) goto er; /archives/netdev/2005-01/msg00064.html (12,396 bytes)
9. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 4 Jan 2005 23:36:12 +0100; Updated patch with the following changes (still untested) * destroy/dump/change are not optional (only match is required) * ematch can set datalen in ematch_ops to have the ematch api do a data lengt; /archives/netdev/2005-01/msg00072.html (32,487 bytes)
10. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 04 Jan 2005 21:54:54 -0500; 50K matches is probably senseless - i was talking about rules (which contain matches). I think this is a debate that can be easily settled ;-> Agreed logic will beat brute force smartness and u32 is; /archives/netdev/2005-01/msg00076.html (12,253 bytes)
11. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 04 Jan 2005 22:12:08 -0500; This is 1 of 2 parts i think thats still an issue; otherwise looks very good. Why do i need to signal something as simple? AND why does it have to be 32 bit type - what edge does that give you? I sho; /archives/netdev/2005-01/msg00077.html (11,690 bytes)
12. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 5 Jan 2005 12:00:48 +0100; * jamal <1104894728.1117.56.camel@xxxxxxxxxxxxxxxx> 2005-01-04 22:12 You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE set will simply result in allocating & copy. It's an optimiz; /archives/netdev/2005-01/msg00098.html (19,107 bytes)
13. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 5 Jan 2005 12:09:17 +0100; * jamal <1104893694.1124.37.camel@xxxxxxxxxxxxxxxx> 2005-01-04 21:54 Absolutely. Actually the goal of basic is to be an alternative to u32 if hashing is not required because I think adding hashing wi; /archives/netdev/2005-01/msg00099.html (11,250 bytes)
14. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Florian Weimer <fw@xxxxxxxxxxxxx>; Date: Wed, 05 Jan 2005 14:32:29 +0100; * Thomas Graf: This might infringe US patent 5,793,954 and the patents that reference it. 8-(; /archives/netdev/2005-01/msg00101.html (8,601 bytes)
15. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 05 Jan 2005 08:45:18 -0500; hehe. We can sleep better knowing we dont run Linux using C++ ;-> That patents reads like it owns every classifier ever written in C++ that runs on a processor. cheers, jamal; /archives/netdev/2005-01/msg00102.html (9,272 bytes)
16. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 05 Jan 2005 08:33:11 -0500; Sorry i missed that. Isnt it still unecessary though? You should be able to pass L=4 and not need the speacial treatment, no? Indeed this is what i was thinking of. The only added overhead I can thin; /archives/netdev/2005-01/msg00103.html (17,748 bytes)
17. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 5 Jan 2005 15:45:14 +0100; * jamal <1104931991.1117.152.camel@xxxxxxxxxxxxxxxx> 2005-01-05 08:33 Agreed, but the ematch might expect an allocated block. Assuming the data is variable and sometimes is L=4, sometimes L=16 the em; /archives/netdev/2005-01/msg00107.html (15,963 bytes)
18. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 5 Jan 2005 17:48:32 +0100; Here's what I mean, it moves the u32 match as-is to an ematch so it benefits from logic relations, inversion and can be used from other classifiers as well. All we have to do is set info->ptr and tr; /archives/netdev/2005-01/msg00112.html (15,746 bytes)
19. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 06 Jan 2005 08:47:05 -0500; Sorry for the latency - vacation over, i am gonna slow down a little .. [..] So the issue is whether its by ref or copy? Maybe thats what the flag is for then. My view is that _everything_ for ematch; /archives/netdev/2005-01/msg00144.html (18,135 bytes)
20. Re: [RFC] ematch API, u32 ematch, nbyte ematch, basic classifier (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 06 Jan 2005 09:03:57 -0500; I think this is fine; getting into complicated-land with off2 etc but fine and does not preclude (and is lower importance in my opinion) than having u32 do its own magic. Note again Thomas: I do real; /archives/netdev/2005-01/msg00147.html (11,848 bytes)

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